Hi, +1 for the idea. I Haven't reviewed the patches yet, but I would like to
share some thoughts.
On Fri, Feb 28, 2025 at 5:32 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> > One thing I am wondering is whether extensions should be required to
> > prefix their EXPLAIN option with the extension name to avoid
> > collisions.
>
> I considered that. One advantage of doing that is that you could
> support autoloading. Right now, you have to LOAD 'pg_overexplain' or
> put it in session_preload_libraries or shared_preload_libraries in
> order to use it. If you required people to type EXPLAIN
> (pg_overexplain.range_table) instead of just EXPLAIN (range_table),
> then you could react to not finding any such option by trying to
> autoload a .so with the part of the name before the dot.
>
> But you can probably see that this idea has a couple of pretty serious
> weaknesses:
>
> 1. It is much more verbose. I theorize that people will be unhappy
> about having to type EXPLAIN (pg_overexplain.range_table) rather than
> just EXPLAIN (range_table). One could try to address this by renaming
> the extension to something shorter, like just 'oe'. Having to type
> EXPLAIN (oe.range_table) wouldn't be nearly as annoying. However, this
> seems like a pretty clear case of letting the tail wag the dog.
>
> 2. autoloading could have security concerns. This is probably fixable,
> but we'd need to be sure that providing a new way to trigger loading a
> module didn't open up any security holes.
>
> > If two extensions happen to choose the same name, it won't be possible
> > to use both simultaneously.
>
> That's true. Of course, a lot depends on whether we end up with 3 or 5
> or 8 EXPLAIN extensions or more like 30 or 50 or 80. In the former
> case, the people writing those extensions will probably mostly know
> about each other and can just use different names. In the latter case
> it's a problem. My guess is it's the former case.
>
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.
This is a similar behaviour when, e.g we have a where clause that is
referencing a column that is present in multiple tables used in the query:
ERROR: 42702: column reference "b" is ambiguous LINE 1: select * from t inner
join t2 on t.a = t2.a where b = 10;
--
Matheus Alcantara