Greetings,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >> * Rather than adding a core-server feature, the remote-end part of the new
> >> API should be a function installed by an extension (either postgres_fdw
> >> itself, or a new extension "postgres_fdw_remote" or the like).
>
> > I'm trying to figure out why it makes more sense to use
> > 'postgres_fdw_support(query text)', which would still do parse/plan and
> > return EXPLAIN-like data, rather than having:
>
> > EXPLAIN (FORMAT JSON, FDW true) query ...
>
> I see a couple of reasons not to do it like that:
>
> 1. This is specific to postgres_fdw. Some other extension might want some
> other data, and different versions of postgres_fdw might want different
> data. So putting it into core seems like the wrong thing.
Another extension or use-case might want exactly the same information
too though. In a way, we'd be 'hiding' that information from other
potential users unless they want to install their own extension, which
is a pretty big leap. Are we sure this information wouldn't be at all
interesting to pgAdmin4 or explain.depesz.com?
> 2. Wedging this into EXPLAIN would be quite ugly, because (at least
> as I envision it) the output would have just about nothing to do with
> any existing EXPLAIN output.
This is a better argument for not making it part of EXPLAIN, though I
don't really feel like I've got a decent idea of what you are suggesting
the output *would* look like, so it's difficult for me to agree (or
disagree) about this particular point.
> 3. We surely would not back-patch a core change like this. OTOH, if
> the added infrastructure is in an extension, somebody might want to
> back-patch that (even if unofficially). This argument falls to the
> ground of course if we're forced to make any core changes to be able
> to get at the data we need; but I'm not sure that will be needed.
Since postgres_fdw is part of core and core's release cycle, and the
packagers manage the extensions from core in a way that they have to
match up, this argument doesn't hold any weight with me. For this to be
a viable argument, we would need to segregate extensions from core and
give them their own release cycle and clear indication of which
extension versions work with which PG major versions, etc. I'm actually
generally in support of *that* idea- and with that, would agree with
your point 3 above, but that's not the reality of today.
Thanks,
Stephen
