Re: Refactor query normalization into core query jumbling - Mailing list pgsql-hackers

From Bertrand Drouvot
Subject Re: Refactor query normalization into core query jumbling
Date
Msg-id aVOJrJ4wP/6pHuwz@ip-10-97-1-34.eu-west-3.compute.internal
Whole thread Raw
In response to Re: Refactor query normalization into core query jumbling  (Sami Imseih <samimseih@gmail.com>)
List pgsql-hackers
Hi,

On Tue, Dec 23, 2025 at 10:35:18AM -0600, Sami Imseih wrote:
> v3 implements this approach without a callback. This establishes a clear
> boundary: core owns JumbleState modifications, extensions consume the
> results through the API.
> 

Thanks for the new patch version.

Some random comments:

=== 1

+       SetConstantLengths((JumbleState *) jstate, query, query_loc);

This cast seems unnecessary.

=== 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? 

=== 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?

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Re: Improve logical replication usability when tables lack primary keys
Next
From: Alexander Pyhalov
Date:
Subject: Re: Limit memory usage by postgres_fdw batches