Extensions, patch v16

Hi,

Please find attached revision 16 of the extension patch, with the
following additions over the previous one:

 - added documentation as proposed by David Wheeler, you can browse it
   online if reading SGML ain't your thing

   http://pgsql.tapoueh.org/extensions/doc/html/extend-extension.html

 - renamed pg_extensions system view to pg_available_extensions

 - add ALTER EXTENSION SET SCHEMA command

   so that I'm going to mark the patch for that as rejected, where it's
   in fact deprecated: it turned out we already need it as part of the
   main patch here

 - add support for 'relocatable' boolean property in the control file,
   as discussed on list

   this controls what happens at create extension time, by doing a
   relocation of the extension objects when the extension is relocatable
   and the asked schema isn't the first of the search_path (you can't
   relocate an object to a schema where it already is)

   when the extension is not relocatable, the mechanism used is the
   @extschema@ replacement in the script so that the user still has a
   say, but at create time only

 - adapt all contrib

   the SET search_path TO public, which became TO @extschema@, is now
   removed

   2 contribs are not relocatable: adminpack installs its functions
   directly into pg_catalog and earthdistance depends on cube.

   As we said we won't support extension dependencies in the first cut,
   there's no guard in the dependency recursion that would allow us not
   to relocate cube objects when relocating earthdistance. The easiest
   solution seemed to me to mark the earthdistance extension as not
   relocatable.

 - nothing is done for the psql commands \dx and \dx+, here's an idea:

   \dx lists only installed extensions
   \dx+ <extension> lists the objects, calling pg_extension_objects()
   \dX lists available extensions (and installed too)

 - we still depend on extension authors providing a control file. Do we
   want to spend some efforts on trying to get rid of this file? I know
   David desperately want to, but that's at the cost of making it much
   harder to manage more than one extension in a single directory, for
   once, and the Makefile mechanisms to make than happen (include a rule
   depending on the presence of some variables, keep track of it for the
   cleaning, etc) doesn't seem to me to worth it.

 - this patch still includes the current version of pg_execute_from_file
   patch, and the next thing I'm going to do is have it change
   underneath us to remove some SQL visible functions that shouldn't
   exists. Please don't focus on that part of the changes.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support