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