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

st 18. 11. 2020 v 6:58 odesílatel Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
napsal:

>
>
> út 17. 11. 2020 v 21:45 odesílatel Chapman Flack <chap(at)anastigmatix(dot)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
>

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 $$
#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)

> 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
>>
>