Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Providing types for plpgsql function signature #126

Open
jsommr opened this issue Dec 30, 2021 · 0 comments
Open

Providing types for plpgsql function signature #126

jsommr opened this issue Dec 30, 2021 · 0 comments
Labels

Comments

@jsommr
Copy link

jsommr commented Dec 30, 2021

"UNKNOWN" is currently returned for all types in a plpgsql function signature because of this:

argdtype = plpgsql_build_datatype(UNKNOWNOID, -1, InvalidOid, NULL);

Which calls a mocked function:

runner.mock('plpgsql_build_datatype', 'PLpgSQL_type * plpgsql_build_datatype(Oid typeOid, int32 typmod, Oid collation, TypeName *origtypname) { PLpgSQL_type *typ; typ = (PLpgSQL_type *) palloc0(sizeof(PLpgSQL_type)); typ->typname = pstrdup("UNKNOWN"); typ->ttype = PLPGSQL_TTYPE_SCALAR; return typ; }')

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?

@lfittl lfittl added the plpgsql label Nov 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants