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

čt 6. 1. 2022 v 17:48 odesílatel Joel Jacobson <joel(at)compiler(dot)org> napsal:

> On Thu, Jan 6, 2022, at 17:10, Pavel Stehule wrote:
> > I understand well, and I don't think it's nice.
> >
> > Are there some similar features in other programming languages?
>
> It would be similar to "this" in Javascript/Java/C++,
> but instead using "in" to access function parameters.
>
> Currently, we need to prefix the parameter name if it's in conflict with a
> column name:
>
> CREATE FUNCTION very_long_function_name(id int, some_value text)
> RETURNS boolean
> LANGUAGE sql AS $$
> UPDATE some_table
> SET some_value = very_long_function_name.some_value
> WHERE id = very_long_function_name.id RETURNING TRUE
> $$;
>
> This is cumbersome as function names can be long, and if changing the
> function name,
> you would need to update all occurrences of the function name in the code.
>
> If we could instead refer to the parameters by prefixing them with "in.",
> we could write:
>
> CREATE FUNCTION very_long_function_name(id int, some_value text)
> RETURNS boolean
> LANGUAGE sql AS $$
> UPDATE some_table
> SET some_value = in.some_value
> WHERE id = in.id RETURNING TRUE
> $$;
>
> I think this would be nice, even if it would only work for IN parameters,
> since you seldom need to access OUT parameters in the problematic
> WHERE-clauses anyway.
> I mostly use OUT parameters when setting them on a separate row:
> some_out_var := some_value;
> ...or, when SELECTin INTO an OUT parameter, which wouldn't be a problem.
>

There is full agreement in a description of the issue. Just I don't like
the proposed solution. The word "in '' is not too practical (where there
are out, and inout) - and it goes against the philosophy of ADA, where all
labels are parametrized (there is not any buildin label). The ADA language
has two things that plpgsql has not (unfortunately): a) possibility to
modify (configure) compiler by PRAGMA directive, b) possibility to define
PRAGMA on more levels - package, function, block. The possibility to define
a label dynamically is a better solution (not by some buildin keyword),
because it allows some possibility for the end user to define what he
prefers. For some cases "in" can be ok, but when you have only two out
variables, then "in" looks a little bit strange, and I prefer "fx", other
people can prefer "a" or "args".

There is no technical problem in the definition of alias of top namespace.
The problem is in syntax and in forcing this setting to some set of
routines. Theoretically we can have GUC plpgsql.rootns. I can set there
"fx", and you can set there "in" and we both can be happy. But the real
question is - how to force this setting to all functions. GUC can be
overwritten in session, and although you can set this GUC in every
function (by option or by assigned GUC), it is not nice, and somebody can
forget about this setting. For me, there are more interesting (important)
issues than the possibility to specify the root namespace that can be nice
to control. I miss some configuration mechanism independent of GUC that is
static (and that emulates static compile options), that can be assigned to
database (as synonym for project) or schema (as synonym for module or
package). With this mechanism this thread will be significantly shorter,
and all discussion about plpgsql2 was not.

>
> > you can check it. It is true, so IN is usually followed by "(", but
> until check I am not able to say if there will be an unwanted
> > shift or collision or not.
>
> I checked gram.y, and IN_P is never followed by '.', but not sure if it
> could cause problems anyway, hope someone with parser knowledge can comment
> on this.
>
> /Joel
>