Re: RFC: extensible planner state - Mailing list pgsql-hackers

From Melanie Plageman
Subject Re: RFC: extensible planner state
Date
Msg-id CAAKRu_Zg-8xj67kYr+pB68MO4urpYT=1tuaQUSJBhPVkan6Q3A@mail.gmail.com
Whole thread Raw
In response to Re: RFC: extensible planner state  (Andrei Lepikhov <lepihov@gmail.com>)
Responses Re: RFC: extensible planner state
List pgsql-hackers
On Tue, Aug 26, 2025 at 4:58 AM Andrei Lepikhov <lepihov@gmail.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_waldump: support decoding of WAL inside tarfile
Next
From: Nico Williams
Date:
Subject: Re: PostgreSQL 18 GA press release draft