| From: | Sami Imseih <samimseih(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| 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 03:12:08 |
| Message-ID: | CAA5RZ0sBuoJ6-z6NAVA8AmnzVz3y74xjo8N0Um9K-Nh+1AHFrg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> 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.
Allowing extensions to generate code for custom node attributes could be
taken up in 19. What about for 18 we think about exposing AppendJumble,
JUMBLE_FIELD, JUMBLE_FIELD_SINGLE and JUMBLE_STRING?
—
Sami Imseih
Amazon Web Services (AWs)
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2025-03-26 03:52:33 | Re: Possibly hard-to-read message |
| Previous Message | Kyotaro Horiguchi | 2025-03-26 03:07:32 | Possibly hard-to-read message |