Re: BUG #9068: invalid YY_START on Unicode identifier escape syntax
От | Manuel Gómez |
---|---|
Тема | Re: BUG #9068: invalid YY_START on Unicode identifier escape syntax |
Дата | |
Msg-id | CAJWnFaPSXF39KRHpxHKFU2-SoxT0KDaMcwAxW+eLH9TDuwO3YQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #9068: invalid YY_START on Unicode identifier escape syntax (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Sun, Feb 2, 2014 at 7:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > targen@gmail.com writes: >> Long story short: > >> manuel@debian $ psql >> psql (9.3.2) >> Type "help" for help. > >> manuel=# U&"""" >> invalid YY_START >> manuel@debian $ > > Fixed, thanks for the report! > > regards, tom lane Thanks! Just tested this though, and I’m not sure it’s really working as intended: manuel@debian $ printf '%s\n' 'select 42 as U&"a"' | psql ERROR: syntax error at end of input LINE 1: select 42 asU&"a" ^ manuel@debian $ printf '%s\n' 'select 42 as "a"' | psql a ---- 42 (1 row) manuel@lechuza $ psql psql (9.4devel) Type "help" for help. manuel=# select 42 as U&"a" manuel-# (after that last command, it correctly waits for more input) So apparently it works fine in interactive use of psql, but behavior is inconsistent with other sorts of identifier tokens when the end of input is an appropriate substitute for a terminator. This is perhaps a minor annoyance since adding a semicolon solves it. Aside from this, I have a few other bits of code failing, but they seem to be happening in plpgsql — is this form of identifier escaping supposed to work in that context? If so, I can try to produce a minimal failing test case.
В списке pgsql-bugs по дате отправления: