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 CAFj8pRAPiPn97nMgnzbDCu_4pU-QreXLhNY7F=b3OUVS6gABCQ@mail.gmail.com
Whole thread Raw
In response to Re: pl/pgsql feature request: shorthand for argument and local variable references  (Hannu Krosing <hannuk@google.com>)
List pgsql-hackers


čt 18. 3. 2021 v 15:49 odesílatel Hannu Krosing <hannuk@google.com> napsal:
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

just because it can be used in different places - for example in nested blocks. And then you need to create really new aliases for these object in current namespace. And it is not easy because we cannot to iterate in ns_items tree from root



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.

I think this feature allows for more concepts.




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

please, see my previous mail. There was links

On Thu, Mar 18, 2021 at 3:19 PM Hannu Krosing <hannuk@google.com> wrote:
>
> On Thu, Mar 18, 2021 at 5:27 AM Pavel Stehule <pavel.stehule@gmail.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

pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: pl/pgsql feature request: shorthand for argument and local variable references
Next
From: David Steele
Date:
Subject: Re: Reduce the time required for a database recovery from archive.