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 05:58:21
Message-ID: CAFj8pRBJ0LMhpHOL8hynsNWZ1Orwo9K2U7qpPT9vahA8voXRdg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

ú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

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Li Japin 2020-11-18 06:01:28 Re: Terminate the idle sessions
Previous Message Thomas Munro 2020-11-18 05:10:31 Re: WIP: WAL prefetch (another approach)