> On Thu, Mar 26, 2026 at 10:18 PM Michael Paquier <[email protected]> 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)
