On Wed, Sep 04, 2019 at 12:14:50AM -0400, Tom Lane wrote: > Stephen Frost <sfr...@snowman.net> writes: > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > >> 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. > > > 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. > > I don't think that auto-installing such things requires changing much > of anything. See plpgsql, which is auto-installed now but still sits > in src/pl/ alongside other PLs that are not auto-installed. Similarly, > there's nothing really stopping us from choosing to install some > module of contrib by default; rearranging the source tree is not a > prerequisite to that. > > The situation with pg_stat_statements is more than that, since what > David is requesting is not merely that we auto-install that extension > but that we automatically push it into shared_preload_libraries.
What I am actually suggesting is that it not be a separate library at all, i.e. that all its parts live in PostgreSQL proper. > > ...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. > > A key point that hasn't been highlighted in this discussion is that having > pg_stat_statements as an extension is proof-of-concept that such features > *can* be implemented outside of core. Don't you think that there are > probably people maintaining private variants of that extension, who would > be really sad if we removed or broke APIs they need for it once > pg_stat_statements is part of core? Nowhere near the number of people who are inconvenienced, at a minimum, by the high barriers needed in order to install and use it in its current form. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
