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

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Chapman Flack <chap(at)anastigmatix(dot)net>
Cc: Jack Christensen <jack(at)jncsoftware(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pl/pgsql feature request: shorthand for argument and local variable references
Date: 2020-11-18 20:24:48
Message-ID: CAFj8pRA7Uof8rV0cGoee99UYzXPUyNAj+v3=fw72Diyg8Q54Fw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

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

maybe a better name for this option can be "routine_alias".

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-11-18 20:39:55 Re: More time spending with "delete pending"
Previous Message Pavel Stehule 2020-11-18 20:21:06 Re: pl/pgsql feature request: shorthand for argument and local variable references