On Tue, Nov 17, 2020 at 1:36 PM Pavel Stehule <pavel.steh...@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
