>> 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)
