Re: Refactor query normalization into core query jumbling

> On Thu, Mar 26, 2026 at 10:18 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> > This line of arguments is stronger for the normalization of the query
> > string. Why should the core code decide what a normalized string
> > should look like when it comes to the detection of the constants, if
> > any? Instead of a dollar-quoted number, we could enforce a bunch of
> > things, like a '?' or a '$woozah$' at these locations.
>
> Fair enough, though I haven't seen any extensions that do that in
> practice - its reasonable to have normalization result in a query
> string that's parsable again and can be passed to EXPLAIN
> (GENERIC_PLAN).

with regards to generate_normalized_query, AFAICT, the most common
case is extensions are using it for is dollar quoted number, but I agree
this one is a gray area.

> What if we only put the ComputeConstantLengths (as Sami had it in v7)
> in core, together with making JumbleState const?

I agree that ComputeConstantLengths should be in core. This one is
not a gray area IMO. The query jumble already records constant locations,
but leaves the lengths unset. ComputeConstantLengths is just the
completion of that work. There could be no other interpretation,
unlike generate_normalized_query, of what the lengths should be.

--
Sami Imseih
Amazon Web Services (AWS)