public inbox for [email protected]
help / color / mirror / Atom feedRe: Request for official clarification on SQL parameter parsing changes in PostgreSQL 15 and 16
2+ messages / 2 participants
[nested] [flat]
* Re: Request for official clarification on SQL parameter parsing changes in PostgreSQL 15 and 16
@ 2025-04-17 14:15 Tom Lane <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Tom Lane @ 2025-04-17 14:15 UTC (permalink / raw)
To: Laurenz Albe <[email protected]>; +Cc: 王 博 <[email protected]>; [email protected] <[email protected]>; 李 浩 <[email protected]>
Laurenz Albe <[email protected]> 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 syntax in any
version of Postgres. Something in your client stack must be
translating "?" to "$1", "$2", etc, and so the new 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 around the
parameter symbol. It's really a bug that it didn't do so already,
since closely-adjacent cases like digits immediately after the
"?" would already have caused failures.
regards, tom lane
^ permalink raw reply [nested|flat] 2+ messages in thread
* RE: Request for official clarification on SQL parameter parsing changes in PostgreSQL 15 and 16
@ 2025-04-18 01:38 王 博 <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: 王 博 @ 2025-04-18 01:38 UTC (permalink / raw)
To: Tom Lane <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; +Cc: 李 浩 <[email protected]>
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 issue I was encountering. I really appreciate your time and support.
Best regards,
Wang Bo
-----Original Message-----
From: Tom Lane <[email protected]>
Sent: Thursday, April 17, 2025 11:16 PM
To: Laurenz Albe <[email protected]>
Cc: 王 博 <[email protected]>; [email protected]; 李 浩 <[email protected]>
Subject: Re: Request for official clarification on SQL parameter parsing changes in PostgreSQL 15 and 16
Laurenz Albe <[email protected]> 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 syntax in any version of Postgres. Something in your client stack must be translating "?" to "$1", "$2", etc, and so the new 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 around the parameter symbol. It's really a bug that it didn't do so already, since closely-adjacent cases like digits immediately after the "?" would already have caused failures.
regards, tom lane
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2025-04-18 01:38 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-04-17 14:15 Re: Request for official clarification on SQL parameter parsing changes in PostgreSQL 15 and 16 Tom Lane <[email protected]>
2025-04-18 01:38 ` 王 博 <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox