Re: pl/pgsql feature request: shorthand for argument and local variable references - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: pl/pgsql feature request: shorthand for argument and local variable references
Date
Msg-id CAFj8pRBJ0LMhpHOL8hynsNWZ1Orwo9K2U7qpPT9vahA8voXRdg@mail.gmail.com
Whole thread Raw
In response to Re: pl/pgsql feature request: shorthand for argument and local variable references  (Chapman Flack <chap@anastigmatix.net>)
Responses Re: pl/pgsql feature request: shorthand for argument and local variable references  (Pavel Stehule <pavel.stehule@gmail.com>)
List 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 by date:

Previous
From: Thomas Munro
Date:
Subject: Re: WIP: WAL prefetch (another approach)
Next
From: Li Japin
Date:
Subject: Re: Terminate the idle sessions