On 1/3/22 8:59 PM, Tom Lane wrote:
"Andrey V. Lepikhov" <a.lepik...@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
