Re: queryId constant squashing does not support prepared statements

On Fri, 2 May 2025 14:56:56 +0200
Álvaro Herrera <alvherre(at)kurilemu(dot)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.