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 14:45:16
Message-ID: CAFj8pRCMu5GM7yhiUEyOZ=RG5+F1_NvnHzDknV4xsvg1rv9n0w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

čt 18. 3. 2021 v 15:19 odesílatel Hannu Krosing <hannuk(at)google(dot)com> napsal:

> 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!
>
> it is documented, please look to following links (but #option dump is
undocumented, others are documented)

https://www.postgresql.org/docs/current/plpgsql-implementation.html#PLPGSQL-VAR-SUBST
https://www.postgresql.org/docs/current/plpgsql-statements.html

CREATE FUNCTION get_userid(username text) RETURNS int
AS $$
#print_strict_params on
DECLARE
userid int;
BEGIN
SELECT users.userid INTO STRICT userid
FROM users WHERE users.username = get_userid.username;
RETURN userid;
END;
$$ LANGUAGE plpgsql;

>
> 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;
>

Why you think so it is better than just

#routine_label fnarg

?

Maybe the name of the option can be routine_alias? Is it better for you?

My objection to DECLARE is freedom of this clause. It can be used
everywhere. the effect of DECLARE is block limited. So theoretically
somebody can write

BEGIN
..
DECLARE fnarg ALIAS FOR FUNCTION;
BEGIN
..
END;

END;

It disallows simple implementation.

Regards

Pavel

>
> Cheers
> Hannu
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2021-03-18 14:48:55 Re: pl/pgsql feature request: shorthand for argument and local variable references
Previous Message David Steele 2021-03-18 14:37:40 Re: Reloptions for table access methods