Missing struct fields in SELECT due to Postgres truncation of identifiers

[otto-nordander-yubico]

Describe the bug
When using a combination of a long table and column name Jet fails to map the field to the corresponding struct field resulting in missing data.

If I shorten the names it works as expected.

Environment (please complete the following information):

• OS: MacOS
• Database: Postgres
• Database driver: pgx
• Jet version v2.11.1

Code snippet
Given a table definition:

CREATE TABLE this_is_an_awkwardly_long_table_name (this_is_a_very_long_identifier INTEGER PRIMARY KEY, other_value TEXT NOT NULL);
INSERT INTO this_is_an_awkwardly_long_table_name VALUES (1, 'This is the text');

and a SELECT

stmt := tables.ThisIsAnAwkwardlyLongTableName.SELECT(tables.ThisIsAnAwkwardlyLongTableName.AllColumns)
model := models.ThisIsAnAwkwardlyLongTableName{}
err = stmt.Query(db, &model)

fmt.Println(model)
> {0 This is the text}
   ^ This ID should be 1

Running the generated SQL shows that it's truncated:

SELECT this_is_an_awkwardly_long_table_name.this_is_a_very_long_identifier AS "this_is_an_awkwardly_long_table_name.this_is_a_very_long_identifier",
     this_is_an_awkwardly_long_table_name.other_value AS "this_is_an_awkwardly_long_table_name.other_value"
FROM public.this_is_an_awkwardly_long_table_name;

> NOTICE:  identifier "this_is_an_awkwardly_long_table_name.this_is_a_very_long_identifier" will be truncated to "this_is_an_awkwardly_long_table_name.this_is_a_very_long_identi"

Expected behavior
I expect the struct to be populated with the ID or Jet to return an error.
The current behavior fails silently, and it's quite tricky to understand why.

Edit: added another column to showcase that it's fetched and mapped correctly.

[go-jet]

Hi @otto-nordander-yubico, I don't think we can do much in jet regarding this limit. Identifier length limit is purely postgres config. And according to google, you can either recompile "compile the PostgreSQL software from source and increase that limit" or "use shorter names". Since the database returns just a NOTICE, we can't report an error. Error is being silenced in db.

[otto-nordander-yubico]

Hi @otto-nordander-yubico, I don't think we can do much in jet regarding this limit. Identifier length limit is purely postgres config. And according to google, you can either recompile "compile the PostgreSQL software from source and increase that limit" or "use shorter names". Since the database returns just a NOTICE, we can't report an error. Error is being silenced in db.

I see, I didn't know that it was configurable. It seems that the default is 63 characters, would it be possible to make it configurable in Jet as well so that it would truncate too?
Or perhaps you don't want to add such DB specific configuration.

[go-jet]

Identifier length limit is postgres compile time config. Meaning to change the config you need to download postgres source code, change the config and compile postgres your self. This obviously is not a recommended approach.

IMO you can either make you database identifiers smaller or you can re-alias every column manually:

stmt := SELECT(
	tables.ThisIsAnAwkwardlyLongTableName.ThisIsAVeryLongIdentifier.AS("short_table_name.short_ident"),
).FROM(tables.ThisIsAnAwkwardlyLongTableName)

type ShortTableName struct {
	ShortIdent int
}

var dest ShortTableName

err := stmt.Query(db, &dest)

[otto-nordander-yubico]

Identifier length limit is postgres compile time config. Meaning to change the config you need to download postgres source code, change the config and compile postgres your self. This obviously is not a recommended approach.

IMO you can either make you database identifiers smaller or you can re-alias every column manually:

stmt := SELECT(
	tables.ThisIsAnAwkwardlyLongTableName.ThisIsAVeryLongIdentifier.AS("short_table_name.short_ident"),
).FROM(tables.ThisIsAnAwkwardlyLongTableName)

type ShortTableName struct {
	ShortIdent int
}

var dest ShortTableName

err := stmt.Query(db, &dest)

Yeah that's very cumbersome and not feasible for me.
I'll look into trying to scan for such occurrences on our end instead.
Thanks for the swift responses, I guess we can close this now.