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@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us