RE: Request for official clarification on SQL parameter parsing changes in PostgreSQL 15 and 16

Dear Tom, Laurenz, and Dominique,

Thank you all very much for your helpful and detailed explanations.

Your insights clarified the behavior change in PostgreSQL 15 perfectly, and I now have a clear understanding of the
issueI was encountering. I really appreciate your time and support.
 

Best regards,  
Wang Bo


-----Original Message-----
From: Tom Lane <tgl@sss.pgh.pa.us> 
Sent: Thursday, April 17, 2025 11:16 PM
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: 王　博 <bo.wang@infortech.co.jp>; pgsql-general@lists.postgresql.org; 李　浩 <hao.li@infortech.co.jp>
Subject: Re: Request for official clarification on SQL parameter parsing changes in PostgreSQL 15 and 16

Laurenz Albe <laurenz.albe@cybertec.at> writes:
> On Thu, 2025-04-17 at 05:17 +0000, 王　博 wrote:
>> 1. In PostgreSQL 15 and later:
>>    The following SQL causes a syntax error unless a space is added after the `?`:
>>      SELECT * FROM table WHERE a = ?AND b = 123;
>>    → Adding a space (`? AND`) resolves the issue.

> I'd say it is this change:
> https://postgr.es/c/2549f0661bd28571d7200d6f82f752a7ee5d47e1

Yeah.  This looks like "?" ought to be parsable as a separate token ... but as Dominique noted, it's not actually legal
syntaxin any version of Postgres.  Something in your client stack must be translating "?" to "$1", "$2", etc, and so
thenew prohibition against junk trailing a number applies.
 

You could fix this without application-level changes if you fixed whatever is making that substitution to add spaces
aroundthe parameter symbol.  It's really a bug that it didn't do so already, since closely-adjacent cases like digits
immediatelyafter the "?" would already have caused failures.
 

            regards, tom lane