On 1/3/22 8:59 PM, Tom Lane wrote:
> "Andrey V. Lepikhov" <a.lepikhov@postgrespro.ru> writes:
>> planner hook is frequently used in monitoring and advising extensions.
>
> Yeah.
>
>> The call to this hook is implemented in the way, that the
>> standard_planner routine must be called at least once in the hook's call
>> chain.
>> But, as I see in [1], it should allow us "... replace the planner
>> altogether".
>> In such situation it haven't sense to call standard_planner at all.
>
> That's possible in theory, but who's going to do it in practice?
We use it in an extension that freezes a plan for specific parameterized
query (using plancache + shared storage) - exactly the same technique as
extended query protocol does, but spreading across all backends.
As I know, the community doesn't like such features, and we use it in
enterprise code only.
>> But, maybe more simple solution is to describe requirements to such kind
>> of extensions in the code and documentation (See patch in attachment)?
>> + * 2. If your extension implements some planning activity, write in the extension
>> + * docs a requirement to set the extension at the begining of shared libraries list.
>
> This advice seems pretty unhelpful. If more than one extension is
> getting into the planner_hook, they can't all be first.
I want to check planner_hook on startup and log an error if it isn't
NULL and give a user an advice how to fix it. I want to legalize this
logic, if permissible.
>
> (Also, largely the same issue applies to very many of our other
> hooks.)
Agreed. Interference between extensions is a very annoying issue now.
--
regards,
Andrey Lepikhov
Postgres Professional