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