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

From: Hannu Krosing <hannuk(at)google(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Vik Fearing <vik(at)postgresfriends(dot)org>, Chapman Flack <chap(at)anastigmatix(dot)net>, 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: 2021-03-18 14:48:55
Message-ID: CAMT0RQQVekNAuZv1aT64Mepi0kjAt32Fwzn9RzGGC__-C4yRAQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I went to archives and read the whole discussion for this from the beginning

I did not really understand, why using the ALIAS FOR syntax is significantly
harder to implement then #routine_label

The things you mentioned as currently using #OPTION seem to be in a different
category from the aliases and block labels - they are more like pragmas - so to
me it still feels inconsistent to use #routine_label for renaming the
outer namespace.

Also checked code and indeed there is support for #OPTION DUMP and
#VARIABLE_CONFLICT ERROR
Is it documented and just hard to find ?

On Thu, Mar 18, 2021 at 3:19 PM Hannu Krosing <hannuk(at)google(dot)com> wrote:
>
> On Thu, Mar 18, 2021 at 5:27 AM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> >
> >
> > There are few main reasons:
> >
> > a) compile options are available already - so I don't need invent new syntax - #OPTION DUMP, #PRINT_STRICT ON, #VARIABLE_CONFLICT ERROR
>
> Are these documented anywhere ?
>
> At least a quick search for pl/pgsql + #OPTION DUMP, #PRINT_STRICT ON,
> #VARIABLE_CONFLICT ERROR returned nothing relevant and also searching
> in
>
> If pl/pgsql actually supports any of these, these should get documented!
>
>
>
> For me the most logical place for declaring a function name alias
> would be to allow ALIAS FOR the function name in DECLARE section.
>
> plpgsql_test=# CREATE FUNCTION
> a_function_with_an_inconveniently_long_name(i int , OUT o int)
> LANGUAGE plpgsql AS $plpgsql$
> DECLARE
> fnarg ALIAS FOR a_function_with_an_inconveniently_long_name;
> BEGIN
> fnarg.o = 2 * fnarg.i;
> END;
> $plpgsql$;
>
> but unfortunately this currently returns
>
> ERROR: 42704: variable "a_function_with_an_inconveniently_long_name"
> does not exist
> LINE 4: fnarg ALIAS FOR a_function_with_an_inconveniently_long_na...
> ^
> LOCATION: plpgsql_yyparse, pl_gram.y:677
>
> Variation could be
>
> DECLARE
> fnarg ALIAS FOR FUNCTION a_function_with_an_inconveniently_long_name;
>
> so it is clear that we are aliasing current function name
>
> or even make the function name optional, as there can only be one, so
>
> DECLARE
> fnarg ALIAS FOR FUNCTION;
>
>
> Cheers
> Hannu

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2021-03-18 14:59:33 Re: pl/pgsql feature request: shorthand for argument and local variable references
Previous Message Pavel Stehule 2021-03-18 14:45:16 Re: pl/pgsql feature request: shorthand for argument and local variable references