From: | "Joel Jacobson" <joel(at)compiler(dot)org> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pl/pgsql feature request: shorthand for argument and local variable references |
Date: | 2022-01-06 13:28:10 |
Message-ID: | a1a9284a-4880-4239-8f5c-e63d83905288@www.fastmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 6, 2022, at 10:05, Julien Rouhaud wrote:
> I agree, but on the other hand I don't see how defining a top level block
> alias identical for every single plpgsql function would really make sense.
> Not every function has a very long name and would benefit from it, and no one
> can really assume that e.g. "root" or whatever configured name won't be used in
> any plpgsql function on that database or cluster. So while having some global
> configuration infrastructure can be useful I still don't think that it could be
> used for this purpose.
How about using the existing reserved keyword "in" followed by "." (dot) and then the function parameter name?
This idea is based on the assumption "in." would always be a syntax error everywhere in both SQL and PL/pgSQL,
so if we would introduce such a syntax, no existing code could be affected, except currently invalid code.
I wouldn't mind using "in." to refer to IN/OUT/INOUT parameters and not only IN ones, it's a minor confusion that could be explained in the docs.
Also, "out." wouldn't work, since "out" is not a reserved keyword.
/Joel
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2022-01-06 13:52:01 | Re: Make relfile tombstone files conditional on WAL level |
Previous Message | Finnerty, Jim | 2022-01-06 13:15:19 | Re: Add 64-bit XIDs into PostgreSQL 15 |