Re: RFC: extensible planner state
От | Melanie Plageman |
---|---|
Тема | Re: RFC: extensible planner state |
Дата | |
Msg-id | CAAKRu_Zg-8xj67kYr+pB68MO4urpYT=1tuaQUSJBhPVkan6Q3A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RFC: extensible planner state (Andrei Lepikhov <lepihov@gmail.com>) |
Ответы |
Re: RFC: extensible planner state
|
Список | 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 по дате отправления: