small bug in ecpg unicode identifier error handling
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.
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
I think this patch is necessary: - if (literallen == 2) /* "U&" */ + if (literallen == 0)
Seems sensible, and matches the corresponding code in scan.l.
+1.
regards, tom lane
On 10.01.22 14:14, Peter Eisentraut wrote:
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.
Committed.
For the record, the correct test case was actually
exec sql select u&"";