Re: Proposal: roll pg_stat_statements into core

Greetings,

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> On 2019-Sep-03, Stephen Frost wrote:
> > * David Fetter (david@fetter.org) wrote:
> > > I'd like to $Subject, on by default, with a switch to turn it off for
> > > those really at the outer edges of performance. Some reasons include:
> >
> > Sure, half of contrib should really be in core (amcheck, file_fdw,
> > postgres_fdw, maybe dblink, pageinspect, pg_buffercache,
> > pg_freespacemap, pgstattuple, pg_visibility, sslinfo, maybe pgtrgm..)
> > but we simply haven't got great facilities for either migrating those
> > things into core (particularly during an upgrade..)
>
> I think there is a false dichotomy here.  Migrating an extension out of
> contrib doesn't have to equate making it no longer an extension.  We
> could, instead, keep it being an extension, but move it out of contrib
> and into (say) src/extensions/ so that it becomes installed and
> available by default, but still an extension.  Users won't have to
> install a separate contrib package, but they would still have to run
> CREATE EXTENSION.
>
> We don't incur the upgrade pain if we do that, for one thing.  Also, we
> don't force everybody to have it; and we don't have to invent this
> hypothetical switch to turn it off.

I don't agree that it's a false dichotomy- from a user experience, you
aren't really changing anything with this approach and the entire point
is that most of these things should just be available in core.  Yes,
maybe we need a way to turn on/off things like pg_stat_statements but
that should have been a runtime "track_stat_statements" or some such,
similar to other things like "track_io_timing", not an "independent"
extension that is actually developed, managed, and released just as core
is.

I also don't buy off, not in the *least*, that we can willy-nilly change
things that pg_stat_statements depends on, or the interface of
pg_stat_statements itself, any more than we can change catalog tables
(which is to say- we can, and do, and people have to deal with it, but
we do get to listen to complaints about it and at times consider if a
change is worth it or not to make).  Having it as an extension doesn't
really change any of that for us, imv.

These aren't external extensions and "contrib" hasn't been what it was
originally designed for in years (see pg_audit if you'd like a
relatively recent example of how contrib isn't really for things that
"address a limited audience or are too experimental to be part of the
main source tree" anymore, despite our README in that directory claiming
otherwise).

I wouldn't be against a proposal that moved contrib into a 'src/modules'
or some such just for maintenance but if we aren't installing the ones
that I've suggested above by (and probably others) by default (and
probably sending the others to the bitbucket because they really aren't
core-ready) then there's really not much point in doing anything here.

The one *good* thing about having extensions is really something that we
*should* have a way to do in core- and that's the upgrade path and
the ability to run an upgrade script sanely.  Maybe we can't get there
for all of our catalogs, but it'd sure be nice if we could figure out a
way to do it for some things so that we break at least a few less things
during upgrades.

Thanks,

Stephen