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

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

> On Thu, Jan 6, 2022, at 17:55, Tom Lane wrote:
> > Even if it works today, we could be letting ourselves in for future
> > trouble. The SQL standard is a moving target, and they could easily
> > standardize some future syntax involving IN that creates a problem here.
>
> Perhaps the "in." notation could be standardized by the SQL standard,
> allowing vendors to use such notation without fear of future trouble?
>
> > I think we already have two perfectly satisfactory answers:
> > * qualify parameters with the function name to disambiguate them;
> > * use the ALIAS feature to create an internal, shorter name.
>
> I would say we have two OK workarounds, far from perfect:
> * Qualifying parameters is too verbose. Function names can be long.
> * Having to remap parameters using ALIAS is cumbersome.
>
> This problem is one of my top annoyances with PL/pgSQL.
>

It depends on the programming style. I am accepting so this can be a real
issue, although I have had this necessity only a few times, and I have not
received any feedback from customers about it.

Probably there can be an agreement so somebody uses it more often and
somebody only a few times. If you need it every time, then you need some
global solution. If you use it only a few times, then a local verbose
solution will be prefered, and a global solution can be the source of new
issues.

Maybe they can help if we accept that there are two different problems, and
we should design two different solutions.

1. how to set globally plpgsql root namespace
2. how to set locally plpgsql root namespace

@1 can be solved by (very dirty) GUC plpggsql.root_ns_alias (this is just
first shot, nothing more)
@2 can be solved by #option root_ns_alias or by extending DECLARE by syntax
"fx ALIAS FOR LABEL functioname

I accept that both issues are valid, and I don't think we can find a good
design that solves both issues, because there are different objective
expectations.

Regards

Pavel

> /Joel
>
>
>
>
>