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 | CAFj8pRBJ0LMhpHOL8hynsNWZ1Orwo9K2U7qpPT9vahA8voXRdg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pl/pgsql feature request: shorthand for argument and local variable references (Chapman Flack <chap@anastigmatix.net>) |
Ответы |
Re: pl/pgsql feature request: shorthand for argument and local variable references
|
Список | pgsql-hackers |
út 17. 11. 2020 v 21:45 odesílatel Chapman Flack <chap@anastigmatix.net> napsal:
On 11/17/20 15:18, Jack Christensen wrote:
>> CREATE OR REPLACE FUNCTION very_long_name(par1 int)
>> RETURNS int AS $$
>> #routine_label lnm
>> BEGIN
>> RAISE NOTICE '%', lnm.par1;
Could that be somehow shoehorned into the existing ALIAS syntax, maybe as
DECLARE
lnm ALIAS FOR ALL very_long_name.*;
or something?
I thought about it - but I don't think so this syntax is correct - in your case it should be
lnm.* ALIAS FOR ALL very_long_name.*;
but it looks a little bit scary in ADA based language.
Maybe
DECLARE lnm LABEL ALIAS FOR very_long_name;
or
DECLARE lnm ALIAS FOR LABEL very_long_name;
I think so implementation should not be hard. But there are advantages, disadvantages - 1. label aliasing increases the complexity of variable searching (instead comparing string with name of namespace, you should compare list of names). Probably not too much. 2. The syntax is a little bit harder than #option. Implementation based on #option can just rename top namespace, so there is not any overhead, and parsing #option syntax is pretty simple (and the syntax is shorter). So from implementation reasons I prefer #option based syntax. There is clear zero impact on performance.
Regards
Pavel
(And would it be cool if Table C.1 [1] had some sort of javascript-y
filtering on reservedness categories, for just such kinds of bikeshedding?)
Regards,
-Chap
[1] https://www.postgresql.org/docs/13/sql-keywords-appendix.html#KEYWORDS-TABLE
В списке pgsql-hackers по дате отправления: