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

On Tue, Nov 17, 2020 at 1:36 PM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
wrote:

>
> Personally in your example I very much like notation "update_item.id",
> because there is a clean signal so "id" is the function's argument. When
> you use "$id", then it is not clean if "id" is a local variable or
> function's argument. So your proposal decreases safety :-/. Plus this
> syntax reduces collision only on one side, you should use aliases for sql
> identifiers and again it is not balanced - In MS SQL I can write predicate
> id = @id. But it is not possible in your proposal (and it is not possible
> from compatibility reasons ever).
>
> More we already has a possibility to do ALIAS of any variable
> https://www.postgresql.org/docs/current/plpgsql-declarations.html#PLPGSQL-DECLARATION-ALIAS
>
> I understand that there can be problems with functions with very long
> names.
>

Right. The problem is most pronounced when the function name is long. And
in particular when there are a lot of optional arguments. In this case the
caller will be using named arguments so I want to avoid prefixing the
parameter names. And while alias is an option, that can also get quite
verbose when there are a large number of parameters.

> So I think introducing new syntax is not necessary. The open question is a
> possibility to do aliasing more comfortably. ADA language has a possibility
> to rename function or procedure. But it is much more stronger, than can be
> implemented in plpgsql. Probably the most easy implementation can be a
> possibility to specify a new argument's label with already supported
> #option syntax.
>
> CREATE OR REPLACE FUNCTION very_long_name(par1 int)
> RETURNS int AS $$
> #routine_label lnm
> BEGIN
> RAISE NOTICE '%', lnm.par1;
>
>
I concur. This would be an improvement.

Jack