Re: Why not install pgstattuple by default?

Attached patch is a first cut at what moving one contrib module (in this 
case pg_buffercache) to a new directory structure might look like.  The 
idea is that src/extension could become a place for "first-class" 
extensions to live.  Those are ones community is committed to providing 
in core, but are just better implemented as extensions than in-database 
functions, for reasons that include security.  This idea has been shared 
by a lot of people for a while, only problem is that it wasn't really 
practical to implement cleanly until the extensions code hit.  I think 
it is now, this attempts to prove it.

Since patches involving file renaming are clunky, the changes might be 
easier to see at 
https://github.com/greg2ndQuadrant/postgres/commit/507923e21e963c873a84f1b850d64e895776574f 
where I just pushed this change too.  The install step for the modules 
looks like this now:

gsmith@grace:~/pgwork/src/move-contrib/src/extension/pg_buffercache$ 
make install
/bin/mkdir -p '/home/gsmith/pgwork/inst/move-contrib/lib/postgresql'
/bin/mkdir -p 
'/home/gsmith/pgwork/inst/move-contrib/share/postgresql/extension'
/bin/sh ../../../config/install-sh -c -m 755  pg_buffercache.so 
'/home/gsmith/pgwork/inst/move-contrib/lib/postgresql/pg_buffercache.so'
/bin/sh ../../../config/install-sh -c -m 644 ./pg_buffercache.control 
'/home/gsmith/pgwork/inst/move-contrib/share/postgresql/extension/'
/bin/sh ../../../config/install-sh -c -m 644 ./pg_buffercache--1.0.sql 
./pg_buffercache--unpackaged--1.0.sql  
'/home/gsmith/pgwork/inst/move-contrib/share/postgresql/extension/'
$ psql -c "create extension pg_buffercache"
CREATE EXTENSION

The only clunky bit I wasn't really happy with is the amount of code 
duplication that comes from having a src/extension/Makefile that looks 
almost, but not quite, identical to contrib/Makefile.  The rest of the 
changes don't seem too bad to me, and even that's really only 36 lines 
that aren't touched often.  Yes, the paths are different, so backports 
won't happen without an extra step.  But the code changes required were 
easier than I was expecting, due to the general good modularity of the 
extensions infrastructure.  So long as the result ends up in 
share/postgresql/extension/ , whether they started in contrib/<module> 
or src/extension/<module> doesn't really matter to CREATE EXTENSION.  
But having them broke out this way makes it easy for the default 
Makefile to build and install them all.  (I recognize I didn't do that 
last step yet though)

I'll happily go covert pgstattuple and the rest of the internal 
diagnostics modules to this scheme, and do the doc cleanups, this 
upcoming week if it means I'll be able to use those things without 
installing all of contrib one day.  Ditto for proposing RPM and Debian 
packaging changes that match them.  All that work will get paid back the 
first time I don't have to fill out a bunch of paperwork (again) at a 
customer site justifying why they need to install the contrib [RPM|deb] 
package (which has some scary stuff in it) on all their servers, just so 
I can get some bloat or buffer inspection module.

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