small bug in ecpg unicode identifier error handling

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема small bug in ecpg unicode identifier error handling
Дата
Msg-id 82fafa79-331c-9d65-e51b-8b5d1b2383fc@enterprisedb.com
обсуждение исходный текст
Ответы Re: small bug in ecpg unicode identifier error handling  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: small bug in ecpg unicode identifier error handling  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список pgsql-hackers
I think this patch is necessary:

diff --git a/src/interfaces/ecpg/preproc/pgc.l b/src/interfaces/ecpg/preproc/pgc.l
index 07fee80a9c..3529b2ea86 100644
--- a/src/interfaces/ecpg/preproc/pgc.l
+++ b/src/interfaces/ecpg/preproc/pgc.l
@@ -753,7 +753,7 @@ cppline            {space}*#([^i][A-Za-z]*|{if}|{ifdef}|{ifndef}|{import})((\/\*[^*/]*\*+
                  }
  <xui>{dquote}    {
                      BEGIN(state_before_str_start);
-                    if (literallen == 2) /* "U&" */
+                    if (literallen == 0)
                          mmerror(PARSE_ERROR, ET_ERROR, "zero-length delimited identifier");
                      /* The backend will truncate the identifier here. We do not as it does not change the result. */
                      base_yylval.str = psprintf("U&\"%s\"", literalbuf);

The old code doesn't make sense.  The literallen is the length of the
data in literalbuf, which clearly doesn't include the "U&" as the
comment suggests.

A test case is to preprocess a file like this (ecpg test.pgc):

exec sql select u&"

which currently does *not* give the above error, but it should.



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

Предыдущее
От: Julien Rouhaud
Дата:
Сообщение: Re: ICU for global collation
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_upgrade verbosity when redirecting output to log file