On 13/9/2025 02:16, Robert Haas wrote:
On Fri, Sep 12, 2025 at 4:34 PM Melanie Plageman
<[email protected]> wrote:
On Tue, Aug 26, 2025 at 4:58 AM Andrei Lepikhov <[email protected]> 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?
As I see, the core has never utilised extensibility machinery and
implemented separate fields/hooks for personal needs (FDW is a suitable
example). And I think there are reasons for that. Not the last one, I
guess, security issues.
I have never seen cases with multiple extensions in the same module. I
wonder what the reason is for doing this and why the core should support
it?>
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.
Yes, but it costs extension developers to complicate the code.
Considering that extensions, implementing planner tricks usually want to
show the user (on an EXPLAIN request) how they impacted the query plan,
I guess it makes sense to suggest the same ID.
But I still vote against extension_id in the planner. The main reason
for me to let go such a solution in EXPLAIN was the 'settings' option,
because extensions may fight for a 'nice' name. But each extension has a
native ID - its personal name, isn't it?>
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?
PlannedStmt in 0004 has an extension list that should contain DefElem
nodes. However, the optimiser nodes use a different approach: the
extension developer must operate with an ID allocation. I propose using
a unified way for extensibility - a list with DefElem, uniquely
identified by module name, looks much more flexible.>
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.
I tried to highlight here that 0004 looks better and more universal than
0001.
--
regards, Andrei Lepikhov
