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

From Dmitry Dolgov
Subject Re: queryId constant squashing does not support prepared statements
Date
Msg-id rdbjpxg3jxjlodcdi6wzj2bpytbvtlys55q6are434mqrium5q@g6egl2va4osm
Whole thread Raw
In response to Re: queryId constant squashing does not support prepared statements  (Sami Imseih <samimseih@gmail.com>)
Responses Re: queryId constant squashing does not support prepared statements
List pgsql-hackers
> On Tue, May 06, 2025 at 01:32:48PM GMT, Sami Imseih wrote:
> > I also agree with Alvaro that this discussion doesn't justify a
> > revert.  If the pre-v18 behavior wasn't chiseled on stone tablets,
> > the new behavior isn't either.  We can improve it some more later.
>
> As I was looking further into what we currently have in v18 and HEAD
> the normalization could break if we pass a function.
>
> [...]
>
> Without properly accounting for the boundaries of the list of expressions, i.e.,
> the start and end positions of '(' and ')' or '[' and ']' and normalizing the
> expressions in between, it will be very difficult for the normalization to
> behave sanely.

I don't think having the end location in this case would help -- when it
comes to ParseFuncOrColumn, looks like for coerce functions it just
replaces the original FuncCall with the argument expression. Meaning
that when jumbling we have only the coerce argument expression (Const),
which ends before the closing brace, not the parent expression.

Maybe it would be possible to address thins in not too complicated way
in fill_in_constant_lengths, since it already operates with parsed
tokens.



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: regdatabase
Next
From: Bruce Momjian
Date:
Subject: Re: PG 18 release notes draft committed