Re: queryId constant squashing does not support prepared statements - Mailing list pgsql-hackers

From Jeremy Schneider
Subject Re: queryId constant squashing does not support prepared statements
Date
Msg-id 20250505194403.40b26252@ardentperf.com
Whole thread Raw
In response to Re: queryId constant squashing does not support prepared statements  (Álvaro Herrera <alvherre@kurilemu.de>)
List pgsql-hackers
On Fri, 2 May 2025 14:56:56 +0200
Álvaro Herrera <alvherre@kurilemu.de> wrote:

> On 2025-May-02, Michael Paquier wrote:
>
> > That depends.  If we conclude that tracking this information through
> > the parser based on the start and end positions in a query string
> > for a set of values is more relevant, then we would be redesigning
> > the facility from the ground, so the old approach would not be
> > really relevant..
>
> I disagree that a revert is warranted for this reason.  If you want to
> change the implementation later, that's fine, as long as the user
> interface doesn't change.
>

FWIW, i'm +1 on leaving it in pg18. Prepared statements often look a
little different in other ways, and there are a bunch of other quirks
in how queryid's are calculated too. Didn't there used to be something
with CALL being handled as a utility statement making stored procs look
different from functions?



--
To know the thoughts and deeds that have marked man's progress is to
feel the great heart throbs of humanity through the centuries; and if
one does not feel in these pulsations a heavenward striving, one must
indeed be deaf to the harmonies of life.

Helen Keller. Let Us Have Faith. Doubleday, Doran & Company, 1940.




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Improve hash join's handling of tuples with null join keys
Next
From: Tom Lane
Date:
Subject: Re: queryId constant squashing does not support prepared statements