Re: Request for official clarification on SQL parameter parsing changes in PostgreSQL 15 and 16 - Mailing list pgsql-general

From Tom Lane
Subject Re: Request for official clarification on SQL parameter parsing changes in PostgreSQL 15 and 16
Date
Msg-id 2194846.1744899352@sss.pgh.pa.us
Whole thread Raw
In response to Re: Request for official clarification on SQL parameter parsing changes in PostgreSQL 15 and 16  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses RE: Request for official clarification on SQL parameter parsing changes in PostgreSQL 15 and 16
List pgsql-general
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 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



pgsql-general by date:

Previous
From: Anton Shepelev
Date:
Subject: Re: Cannot turn track_counts on
Next
From: Tom Lane
Date:
Subject: Re: Cannot turn track_counts on