Re: Why not install pgstattuple by default?

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To:
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Why not install pgstattuple by default?
Date: 2011-05-18 14:25:10
Message-ID: 4DD3D6C6.5060006@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.

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

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.

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)

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

Attachment Content-Type Size
move-contrib-v2.patch text/x-patch 240.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2011-05-18 14:30:28 Re: deprecating contrib for PGXN
Previous Message Merlin Moncure 2011-05-18 13:29:54 Re: Passing an array or record to a stored procedure in PostgreSQL