Re: Why not install pgstattuple by default?

On Mon, May 9, 2011 at 1:14 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> On 05/09/2011 10:53 AM, Robert Haas wrote:
>>
>> I would really like to see us try to group things by topic, and not
>> just by whether or not we can all agree that the extension is
>> important enough to be first-class (which is bound to be a bit
>> tendentious).
>
> Having played around with the prototype, I think it doesn't actually matter
> if there's a further division below the new one I introduced.  The main
> thing I think is worth pointing out is that I only feel extensions with no
> external dependencies are worth the trouble of re-classifying here.  If it
> were worth reorganizing contrib just for the sake of categorizing it, that
> would have been done years ago.  The new thing is that extensions make it
> really easy to make some tools available in the server's extensions
> subdirectly, without actually activating them in the default install.
>
> Looking at your list:
>
>> auto_explain
>> oid2name
>> pageinspect
>> pg_buffercache
>> pg_freespacemap
>> pg_stat_statements
>> pg_test_fsync (perhaps)
>> pgrowlocks
>> pgstattuple
>>
>
> oid2name and pg_test_fsync would be out because those are real executables.
>  I'd rather not introduce the risk/complexity of playing around with moving
> standalone utilities of such marginal value.  Whereas I think it sets an
> excellent precedent if the server is shipping with some standard add-ons,
> built using the same extension mechanism available to external code, in the
> core server package.  I'd certainly be happy to add auto_explain and
> pg_stat_statements (also extremely popular things to install for me) to that
> list.

I'm happy enough with that set of guidelines: namely, that we'd use
src/extension only for things that don't require additional
dependencies, and not for things that build standalone executables.
If we're going to move things around, I think we should take the
trouble to categorize them along the way, and your idea of inserting
one more subdirectory under src/extension for grouping seems fine to
me.

I don't think we should be too obstinate about trying to twist the arm
of packagers who (as Tom points out) will do whatever they want in
spite of us, but the current state of contrib, with all sorts of
things of varying type, complexity, and value mixed together cannot
possibly be a good thing. Even if the effect of all this is that some
distributions end up with postgresql-server-instrumentation and
postgresql-server-datatypes packages, rather than putting everything
in postgresql-server, I still think that'd be better than having a
monolithic lump called postgresql-contrib. Heaven only knows what
could be in there (says the sys admin)...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company