Re: Why not install pgstattuple by default?

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.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us