Re: small bug in ecpg unicode identifier error handling

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&"";