| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
| Cc: | Joel Jacobson <joel(at)compiler(dot)org>, 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 16:55:03 |
| Message-ID: | 1085351.1641488103@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> čt 6. 1. 2022 v 16:59 odesílatel Joel Jacobson <joel(at)compiler(dot)org> napsal:
>> How could the SQL parser have a problem with it, if "in" is currently
>> never followed by "." (dot)?
> 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.
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.
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 see no problem here that is worth locking ourselves into unnecessary
syntax assumptions to fix.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2022-01-06 17:08:33 | Re: terminate called after throwing an instance of 'std::bad_alloc' (llvmjit) |
| Previous Message | Joel Jacobson | 2022-01-06 16:47:48 | Re: pl/pgsql feature request: shorthand for argument and local variable references |