Re: Why not install pgstattuple by default? - Mailing list pgsql-hackers

On Wed, May 18, 2011 at 10:25, Greg Smith <greg@2ndquadrant.com> wrote:
> Attached is a second patch to move a number of extensions from contrib/ to
> src/test/.  Extensions there are built by the default built target, making
> installation of the postgresql-XX-contrib package unnecessary for them to be
> available.

+1 in general on the concept :-)


> This request--making some of these additions available without the "contrib"
> name/package being involved--has popped up many times before, and it turys
> out to be really easy to resolve with the new extensions infrastructure.  I
> think it's even a reasonable change to consider applying now, between 9.1
> Beta 1 and Beta 2.  The documentation adjustments are the only serious bit
> left here that I've been able to find, the code changes here are all
> internal to the build process and easy.

Does this include regression tests? Or will they need some mods?

> I moved the following extensions:
>
> auto_explain pageinspect pg_buffercache pg_freespacemap pgrowlocks
> pg_stat_statements pgstattuple
>
> My criteria was picking extensions that:
>
> 1) Don't have any special dependencies
> 2) Are in contrib mainly because they don't need to be internal functions,
> not because their code quality is demo/early
> 3) Tend to be installed on a production server for troubleshooting problems,
> rather than being required by development.
> 4) Regularly pop up as necessary/helpful in production deployment

These seem like reasonable criteria.


> Some of my personal discussions of this topic have suggested that some other
> popular extensions like pgcrypto and hstore get converted too.  I think
> those all fail test (3), and I'm not actually sure where pgcrypto adds any
> special dependency/distribution issues were it to be moved to the main
> database package.  If this general idea catches on, a wider discussion of
> what else should get "promoted" to this extensions area would be
> appropriate.  The ones I picked seemed the easiest to justify by this
> criteria set.

pgcrypto would cause trouble for any builds *without* SSL. I don't
think any packagers do that, but people doing manual builds would
certainly get different results.


> Any packager who grabs the shared/postgresql/extension directory in 9.1,
> which I expect to be all of them, shouldn't need any changes to pick up this
> adjustment.  For example, pgstattuple installs these files:
>
> share/postgresql/extension/pgstattuple--1.0.sql
> share/postgresql/extension/pgstattuple--unpackaged--1.0.sql
> share/postgresql/extension/pgstattuple.control
>
> And these are the same locations they were already at.  The location of the
> source and which target built it is the change here, the result isn't any
> different.  This means that this change won't even break extensions already
> installed.
>
> Once the basic directory plumbing is in place, conversion of a single
> extension from contrib/ to src/test/ is, trivial.  The diff view
>
> I did five of them in an hour once I figured out what was needed.  Easiest
> to view the changes at
> https://github.com/greg2ndQuadrant/postgres/commits/move-contrib , the patch
> file is huge because of all the renames.
> https://github.com/greg2ndQuadrant/postgres/commit/d647091b18c4448c5a582d423f8839ef0c717e91
> show a good example of one convert, that changes pg_freespacemap.  There are
> more changes to the comments listing the name of the file than to any code.
>  (Yes, I know there are some whitespace issues I introduced in the new
> Makefile, they should be fixed by a later commit in the series)

This is where the compare view rocks:

https://github.com/greg2ndQuadrant/postgres/compare/postgres:master...greg2ndQuadrant:move-contrib

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/