From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | 王 博 <bo(dot)wang(at)infortech(dot)co(dot)jp>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>, 李 浩 <hao(dot)li(at)infortech(dot)co(dot)jp> |
Subject: | Re: Request for official clarification on SQL parameter parsing changes in PostgreSQL 15 and 16 |
Date: | 2025-04-17 14:15:52 |
Message-ID: | 2194846.1744899352@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-04-17 14:23:18 | Re: Cannot turn track_counts on |
Previous Message | Anton Shepelev | 2025-04-17 14:05:34 | Re: Cannot turn track_counts on |