Stephen Frost <sfrost@snowman.net> writes:
> * Alvaro Herrera (alvherre@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.
> ...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?
regards, tom lane