Re: Refactor query normalization into core query jumbling

>> backwards compatible. Basically, we keep JumbleState a non-constant,
>> but provide core APIs for any operation, such as
>> generate_normalized_query,
>> that needs to modify the state. So, my approach was not about enforcing a
>> read-only JumbleState, but about providing the API to dissuade an author
>> from modifying a JumbleState.

> Given the lack of public APIs to modify JumbleState today, I don't see how
> an extension would do
> modifications in a meaningful way, short of copying the code. I think we
> should be a bit bolder here in
> enforcing a convention, either clearly making it read-only or dropping the
> argument again.

Based on the discussion so far I am leaning towards making JumbleState
read-only as described here [0]. I don't see how we can drop JumbleState
completely from hooks, since normalization needs to occur on-demand
by the extension.

> 1) An extension that wants to display normalized query strings
>
> This seems to be the biggest kind of what I can find with code search.
> Extensions like pg_stat_monitor [1], that
> want to do something like pg_stat_statements, and have to copy a bunch of
> normalization code today that is 1:1 what
> Postgres does. Such extensions don't need the JumbleState argument if they
> can get the normalized text directly.

Yes, I don't know how that's possible; besides generating the normalized
string during JumbleQuery and making it available to post_parse_analyze
hook ( and other executor hooks ). But this also means we are incurring
the normalization overhead for every execution.

> 2) An extension that wants to capture parameter values
>
> Some extensions may want to remember additional context for normalized
> queries, like pg_tracing's logic for
> optionally passing parameter values (post normalization) in the trace
> context [2]. If we kept passing a read-only
> JumbleState then such extensions could presumably still get this, but I
> wonder if it wouldn't be better for core to
> have a helper for this?

This could be like a core GenerateNormalizedQuery which can optionally
track the constant values. That will be an enhancement to normalization
and a new requirement.

[0] https://www.postgresql.org/message-id/CAA5RZ0sbWmqdUBFo8JXMJe72pnwjxVY58htJ6pKbwnyQuRctQw%40mail.gmail.com

--
Sami Imseih
Amazon Web Services (AWS)