Re: pl/pgsql feature request: shorthand for argument and local variable references

Поиск
Список
Период
Сортировка
От Joel Jacobson
Тема Re: pl/pgsql feature request: shorthand for argument and local variable references
Дата
Msg-id a1a9284a-4880-4239-8f5c-e63d83905288@www.fastmail.com
обсуждение исходный текст
Ответ на Re: pl/pgsql feature request: shorthand for argument and local variable references  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: pl/pgsql feature request: shorthand for argument and local variable references  (Pavel Stehule <pavel.stehule@gmail.com>)
Список 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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Finnerty, Jim"
Дата:
Сообщение: Re: Add 64-bit XIDs into PostgreSQL 15
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Make relfile tombstone files conditional on WAL level