From: | Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Drouvot, Bertrand" <bdrouvot(at)amazon(dot)com>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
Subject: | Re: Generating code for query jumbling through gen_node_support.pl |
Date: | 2023-07-11 06:44:39 |
Message-ID: | 1b92140d-ff31-21cb-3c06-e155471b87ac@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/7/2023 12:35, Michael Paquier wrote:
> On Tue, Jul 11, 2023 at 12:29:29PM +0700, Andrey Lepikhov wrote:
>> I vote for only one method based on a query tree structure.
>
> Noted
>
>> BTW, did you think about different algorithms of queryId generation?
>
> Not really, except if you are referring to the possibility of being
> able to handle differently different portions of the nodes depending
> on a context given by the callers willing to do a query jumbling
> computation. (For example, choose to *not* silence the Const nodes,
> etc.)
Yes, I have two requests on different queryId algorithms:
1. With suppressed Const nodes.
2. With replacement of Oids with full names - to give a chance to see
the same queryId at different instances for the same query.
It is quite trivial to implement, but not easy in support.
>
>> Auto-generated queryId code can open a way for extensions to have
>> easy-supporting custom queryIds.
>
> Extensions can control that at some extent, already.
> --
> Michael
--
regards,
Andrey Lepikhov
Postgres Professional
From | Date | Subject | |
---|---|---|---|
Next Message | Hayato Kuroda (Fujitsu) | 2023-07-11 07:00:03 | RE: doc: clarify the limitation for logical replication when REPILICA IDENTITY is FULL |
Previous Message | Masahiko Sawada | 2023-07-11 06:21:21 | Re: Initial Schema Sync for Logical Replication |