| From: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
|---|---|
| To: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: RFC: extensible planner state |
| Date: | 2025-09-12 20:33:57 |
| Message-ID: | CAAKRu_Zg-8xj67kYr+pB68MO4urpYT=1tuaQUSJBhPVkan6Q3A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Aug 26, 2025 at 4:58 AM Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
>
> 1. Why is it necessary to maintain the GetExplainExtensionId and
> GetPlannerExtensionId routines? It seems that using a single
> extension_id (related to the order of the library inside the
> file_scanner) is more transparent and more straightforward if necessary.
But this wouldn't work for in-core use cases like GEQO, right? Also,
how would it work if there are multiple "extensions" in the same .so
file?
> 2. Why does the extensibility approach in 0001 differ from that in 0004?
> I can imagine it is all about limiting extensions, but anyway, a module
> has access to PlannerInfo, PlannerGlobal, etc. So, this machinery looks
> a little redundant, doesn't it?
What do you mean that the extensibility approach differs? Like that
the type of extension_state is different?
- Melanie
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nico Williams | 2025-09-12 20:48:55 | Re: PostgreSQL 18 GA press release draft |
| Previous Message | Robert Haas | 2025-09-12 20:27:07 | Re: pg_waldump: support decoding of WAL inside tarfile |