You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We see that UNKNOWN is hardcoded because of typ->typname = pstrdup("UNKNOWN");.
It is quite easy to change plpgsql_build_datatype into something that returns a PLpgSQL_type where typname is populated with a given type. Say we have create function test(x customtype, y int) ..... For x the type will be customtype, while it will be pg_catalog.int4 for y because of the way the parser works. Question: Is that the reason this isn't implemented - that built in types are turned into something else for function signatures, while simply being provided as-is from the DECLARE section?
I can't figure out what ideally should be returned here. We do get the original location of the type in the function signature, and can use that to extract the actual written type, like int instead of pg_catalog.int4. It's not super straight forward with signatures like create function complicated(x character(100), y time with time zone default '...', z "mySchema" . sometype[]) etc., but not knowing what would be the right thing to use here, I'd rather ask if some thought have gone into this, or what opinions you have?
The text was updated successfully, but these errors were encountered:
"UNKNOWN"
is currently returned for all types in a plpgsql function signature because of this:libpg_query/src/pg_query_parse_plpgsql.c
Line 193 in d1d0186
Which calls a mocked function:
libpg_query/scripts/extract_source.rb
Line 470 in e9e4ba9
We see that UNKNOWN is hardcoded because of
typ->typname = pstrdup("UNKNOWN");
.It is quite easy to change plpgsql_build_datatype into something that returns a
PLpgSQL_type
wheretypname
is populated with a given type. Say we havecreate function test(x customtype, y int) ....
. For x the type will be customtype, while it will be pg_catalog.int4 for y because of the way the parser works. Question: Is that the reason this isn't implemented - that built in types are turned into something else for function signatures, while simply being provided as-is from the DECLARE section?I can't figure out what ideally should be returned here. We do get the original location of the type in the function signature, and can use that to extract the actual written type, like int instead of pg_catalog.int4. It's not super straight forward with signatures like
create function complicated(x character(100), y time with time zone default '...', z "mySchema" . sometype[])
etc., but not knowing what would be the right thing to use here, I'd rather ask if some thought have gone into this, or what opinions you have?The text was updated successfully, but these errors were encountered: