Re: RFC: extensible planner state

Hmm. I don't have a copy of Andrei's email in my gmail. I see it in
the archives but I have not got it. I don't understand how that
happened. I now wonder if there are other emails from Andrei I haven't
received.

On Fri, Sep 12, 2025 at 4:34 PM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
> 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?

We probably don't want to all extensions on any topic to be allocating
extension IDs from the same space, because it's used as a list index
and we don't want to have to null-pad lists excessively. Combining the
explain and planner cases wouldn't be too much of a stretch, perhaps,
but it's also not really costing us anything to have separate IDs for
those cases.

> > 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?

I suspect the question here is about why not use the
index-by-planner-extension-ID approach for 0004. That could maybe
work, but here everything has to be a Node, so I feel like it would be
more contorted than the existing cases.

--
Robert Haas
EDB: http://www.enterprisedb.com