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 | CAFj8pRByBJ3WE6idLMh9MDaX8fAXBWKw8g0tb-YtrsUCzWirHg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pl/pgsql feature request: shorthand for argument and local variable references (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: pl/pgsql feature request: shorthand for argument and local variable references
Re: pl/pgsql feature request: shorthand for argument and local variable references |
Список | pgsql-hackers |
st 18. 11. 2020 v 6:58 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal:
ú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 belnm.* ALIAS FOR ALL very_long_name.*;but it looks a little bit scary in ADA based language.MaybeDECLARE lnm LABEL ALIAS FOR very_long_name;orDECLARE 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
I checked code - and I have to change my opinion - the current implementation of namespaces in plpgsql doesn't allow renaming or realising labels elegantly. The design has low memory requirements but it is not flexible. I wrote a proof concept patch, and I had to hack the nsitem little bit.
postgres=# create or replace function bubu(a int, b int)
returns void as $$
returns void as $$
#routine_label b
begin
raise notice '% %', b.a, b.b;
end;
$$ language plpgsql;
CREATE FUNCTION
postgres=# select bubu(10,20);
NOTICE: 10 20
┌──────┐
│ bubu │
╞══════╡
│ │
└──────┘
(1 row)
begin
raise notice '% %', b.a, b.b;
end;
$$ language plpgsql;
CREATE FUNCTION
postgres=# select bubu(10,20);
NOTICE: 10 20
┌──────┐
│ bubu │
╞══════╡
│ │
└──────┘
(1 row)
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 по дате отправления: