Re: making EXPLAIN extensible

On Tue, Mar 4, 2025 at 8:56 AM Andrei Lepikhov <lepihov@gmail.com> wrote:
> Passing through the patches, I would say that changing the order of 0001
> and 0002 would make them more independent.

Hmm, I thought this order made sense, but I could reorder them if
there's some compelling reason to do so. If there's no particularly
compelling reason, it would be less work to commit them in this order.

> 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've often thought that the solution to this class of problems could
be to have extensions not manipulate a hook variable directly, but
instead call a function to which they pass their callback function and
an integer priority. Then we could call hook functions in priority
order. One difficulty is that this requires extension authors to agree
on what the priority order should be. In some cases that might not be
too hard, but it isn't apparent how it would work here.

IMHO, it's reasonable for the author of an EXPLAIN extension to say
"well, I see Robert already created an extension with an option called
DEBUG, so I will name my option TROUBLESHOOT," or something of that
sort. But if Robert gave the DEBUG hook priority 50, should I also
give my hook priority 50, or should I make it 40 or 25 or 1 or 100 or
what? Even if I know about all of the other extensions it's not really
clear what I should do. Actually, in this case, it feels like it would
be better if the user could control the ordering somehow, but I feel
like that might be over-engineering.

> I support the way where extensions are allowed to print info but not
> restructure or remove something.
> Wait for the commit!

Cool, thanks.

-- 
Robert Haas
EDB: http://www.enterprisedb.com