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

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Hannu Krosing <hannuk(at)google(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 15:00:24
Message-ID: CAFj8pRAPiPn97nMgnzbDCu_4pU-QreXLhNY7F=b3OUVS6gABCQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

čt 18. 3. 2021 v 15:49 odesílatel Hannu Krosing <hannuk(at)google(dot)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(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

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2021-03-18 15:04:19 Re: Reduce the time required for a database recovery from archive.
Previous Message Hannu Krosing 2021-03-18 14:59:33 Re: pl/pgsql feature request: shorthand for argument and local variable references