Re: pl/pgsql feature request: shorthand for argument and local variable references
От | Pavel Stehule |
---|---|
Тема | Re: pl/pgsql feature request: shorthand for argument and local variable references |
Дата | |
Msg-id | CAFj8pRD_9+LL3EMno7FCsvEm7X3NAa2eRGF1BYd5cSFEau_a8Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pl/pgsql feature request: shorthand for argument and local variable references ("Joel Jacobson" <joel@compiler.org>) |
Ответы |
Re: pl/pgsql feature request: shorthand for argument and local variable references
|
Список | pgsql-hackers |
čt 6. 1. 2022 v 14:28 odesílatel Joel Jacobson <joel@compiler.org> napsal:
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.
You are right, in.outvar looks messy. Moreover, maybe the SQL parser can have a problem with it.
Regards
Pavel
Also, "out." wouldn't work, since "out" is not a reserved keyword./Joel
В списке pgsql-hackers по дате отправления: