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

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!

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;

Cheers
Hannu