From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Sami Imseih <samimseih(at)gmail(dot)com> |
Cc: | Andrei Lepikhov <lepihov(at)gmail(dot)com>, Lukas Fittl <lukas(at)fittl(dot)com>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal - Allow extensions to set a Plan Identifier |
Date: | 2025-03-26 02:43:13 |
Message-ID: | Z-NpwXzwuLR329Pf@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 25, 2025 at 04:23:15PM -0500, Sami Imseih wrote:
> On 3/25/25 00:47, Sami Imseih wrote:
>> 1. Check out the upstream Postgres source for the given version I'm generating jumble code for
>> 2. Modify the headers as needed to have the node attributes I want
>> 3. Call the gen_node_support.pl via the build process
>> 4. Copy out the resulting jumble node funcs/conds
>
> I like this approach, and the artifacts from #4 will be packed with
> the extension.
So this comes down to forking the Postgres code to do the job. What I
had in mind was a slightly different flow, where we would be able to
push custom node attributes between the header parsing and the
generation of the extension code. If we do that, there would be no
need to fork the Postgres code: extensions could force the definitions
they want to the nodes they want to handle, as long as these do not
need to touch the in-core query jumble logic, of course.
Perhaps we should give more time and thoughts to the concepts we want
to expose at this level of the code for extensions. Hence I would
side with not rushing things, and consider our options more carefully
for v19 with what we would consider to be better design.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2025-03-26 03:07:32 | Possibly hard-to-read message |
Previous Message | Richard Guo | 2025-03-26 02:16:26 | Re: Reduce "Var IS [NOT] NULL" quals during constant folding |