Re: pl/pgsql feature request: shorthand for argument and local variable references - Mailing list pgsql-hackers

From Jack Christensen
Subject Re: pl/pgsql feature request: shorthand for argument and local variable references
Date
Msg-id CAMovtNpPbg18Yp-et2mgBxdLh6pv7E_Y9XKmFRZaMOha4vt6pA@mail.gmail.com
Whole thread Raw
In response to Re: pl/pgsql feature request: shorthand for argument and local variable references  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: pl/pgsql feature request: shorthand for argument and local variable references  (Chapman Flack <chap@anastigmatix.net>)
List pgsql-hackers
On Tue, Nov 17, 2020 at 1:36 PM Pavel Stehule <pavel.stehule@gmail.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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_proc.dat "proargmodes is not a 1-D char array"
Next
From: Daniel Gustafsson
Date:
Subject: Re: Move OpenSSL random under USE_OPENSSL_RANDOM