Re: Refactor query normalization into core query jumbling

Sami Imseih <samimseih@gmail.com>

From: Sami Imseih <samimseih@gmail.com>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: zengman <zengman@halodbtech.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-01-05T22:19:27Z
Lists: pgsql-hackers
> === 1
>
> +       SetConstantLengths((JumbleState *) jstate, query, query_loc);
>
> This cast seems unnecessary.

Right. This is unnecessary. I will remove in the next iteration.

> === 2
>
> +CompLocation(const void *a, const void *b)
>
> In the commit message I can see "Functions are renamed to match core naming
> conventions" but wasn't comp_location() better?

Not sure if it's better or worse. I aimed for consistency here and
used pascal case to
match.


> === 3
>
> +                       /*
> +                        * generate the normalized query. Note that the normalized
> +                        * representation may well vary depending on just which
> +                        * "equivalent" query is used to create the hashtable entry. We
> +                        * assume this is OK.
> +                        */
> +                       norm_query = GenerateNormalizedQuery(jstate, query,
>
> Should part of this comment be on top of the GenerateNormalizedQuery()
> definition instead?

No, because this talks about the hashtable entry which is specific to
pg_stat_statements.

--
Sami Imseih
Amazon Web Services (AWS)



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Mark JumbleState as a const in the post_parse_analyze hook

  2. Force standard_conforming_strings to always be ON.

  3. Move pg_stat_statements query jumbling to core.