Re: making EXPLAIN extensible - Mailing list pgsql-hackers

From Robert Haas
Subject Re: making EXPLAIN extensible
Date
Msg-id CA+TgmoZ8sTodL-orXQm51_npNxuDAS86BS5kC8t0LULneShRbg@mail.gmail.com
Whole thread Raw
In response to Re: making EXPLAIN extensible  (Matheus Alcantara <matheusssilv97@gmail.com>)
List pgsql-hackers
First, thanks to all who have said they like this idea. I wasn't
expecting this much enthusiasm, to be honest. Woohoo!

On Mon, Mar 3, 2025 at 8:27 AM Matheus Alcantara
<matheusssilv97@gmail.com> wrote:
> It would make sense (or possible) to have some kind of validation that returns
> an error when using an option that is ambiguous? If a option is unique for all
> options registered via extensions than the extension name prefix is not needed,
> otherwise an error is returned forcing the user to specify the extension name.

I'm not saying that this couldn't be done -- it definitely could --
but to me it seems somewhat pointless. I mean, you'd just get the
error when you try to load the second of the two extensions, and then
what are you supposed to do about it at that point? Really, it's
incumbent on EXPLAIN-extension developers to avoid picking names that
conflict with other EXPLAIN extensions that the same users might want
to use. If they don't do that, everything sucks. By jiggering things
around you can cause the result to be either (a) some options are
ignored (current behavior) or (b) errors occur during extension
loading (your proposal) or (c) errors occur at runtime or even (d)
suddenly the conflicting options need to be spelled in a very verbose
way with a module name prefix instead of using them normally. But I
think no matter which of those things happen, life is pretty bad for
the user. The only real solution, AFAICS, is for the extension
developers to be thoughtful about the option names that they pick.

I'm not saying that's definitely going to happen, and I can be
convinced to add something to the patch to cater to it. But only if we
all agree on exactly what to add and exactly why that's going to be
better than doing nothing. My current view - as explained above - is
that anything we add is just going to be increasing the amount of code
without really making the user experience any better. If that's
correct, it's better to just keep it simple, as I have done.

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



pgsql-hackers by date:

Previous
From: Ilia Evdokimov
Date:
Subject: [PATCH] Improve selectivity estimation for OR clauses with equality conditions on the same column
Next
From: Bertrand Drouvot
Date:
Subject: Re: Log connection establishment timings