Re: plpgsql variable named as SQL keyword

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: plpgsql variable named as SQL keyword
Дата
Msg-id CAFj8pRBdi_13=cRfrBLPQL_nodXPADeE0x4m6fFbPLX4prEP+w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: plpgsql variable named as SQL keyword  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers


čt 28. 2. 2019 v 19:20 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> Maybe we should to disallow variables named as sql reserved keyword.

That would just break existing code.  There are lots of other
examples where you can get away with such things.

We've expended quite a lot of sweat to avoid reserving more names than
we had to in plpgsql.  I'm disinclined to throw that away just because
somebody found an error message confusing.  It's not like reserving
"offset" would cause this case to work.

partially I solved it with new warning in plpgsql_check


postgres=# select * from plpgsql_check_function('omega.foo(int, int, int)');
+-------------------------------------------------------------------------------+
|                            plpgsql_check_function                             |
+-------------------------------------------------------------------------------+
| warning:00000:3:statement block:name of variable "offset" is reserved keyword |
| Detail: The reserved keyword was used as variable name.                       |
| error:42601:4:RETURN:query "SELECT offset + 1" returned 0 columns             |
+-------------------------------------------------------------------------------+
(3 rows)


I understand so it has not simple solution (or had not solution). I reported it +/- for record.

Thank you for reply

Pavel


                        regards, tom lane

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Drop type "smgr"?
Следующее
От: Perumal Raj
Дата:
Сообщение: Re: Question about pg_upgrade from 9.2 to X.X