| From: | "Joel Jacobson" <joel(at)compiler(dot)org> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
| Cc: | "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pl/pgsql feature request: shorthand for argument and local variable references |
| Date: | 2022-01-06 17:17:55 |
| Message-ID: | 251c0e9c-cda9-457f-ae60-4e0ec46affe6@www.fastmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
/Joel
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2022-01-06 17:18:26 | Re: Suggestion: optionally return default value instead of error on failed cast |
| Previous Message | Justin Pryzby | 2022-01-06 17:08:33 | Re: terminate called after throwing an instance of 'std::bad_alloc' (llvmjit) |