Re: making EXPLAIN extensible - Mailing list pgsql-hackers

From Andrei Lepikhov
Subject Re: making EXPLAIN extensible
Date
Msg-id 754369a6-9017-4d5d-8fea-7768e5b94b0f@gmail.com
Whole thread Raw
In response to making EXPLAIN extensible  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: making EXPLAIN extensible
List pgsql-hackers
On 28/2/2025 20:26, Robert Haas wrote:
> So here are some patches.
Yes, this is a big pain for extension developers. As I remember, it was 
discussed multiple times in the hackers' mailing list.
Because there is no explain node hook, I use a patch in almost each of 
my extensions: I write optimisation helpers, and it is necessary to show 
which node was influenced and how. I guess pg_hint_plan will also profit 
from this extra extensibility.

Passing through the patches, I would say that changing the order of 0001 
and 0002 would make them more independent.
Also, I'm ok with the floating order of extension messages in the 
explain output. We get used to living with dependencies on extension 
load order (pg_stat_statements quite annoyingly impacts queryid, for 
example), and this issue should be solved generally, in my opinion.
I support the way where extensions are allowed to print info but not 
restructure or remove something.
Wait for the commit!

-- 
regards, Andrei Lepikhov



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: what's going on with lapwing?
Next
From: Mark Dilger
Date:
Subject: Re: SQL:2023 JSON simplified accessor support