Joshua D. Drake wrote:
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
So what are we thinking here? Along with my suggestion of extensions /
contrib that we modify initdb to load an extensions schema with all
extensions into template1?
No, I don't think so.  If you do that it's effectively moving all that
stuff into core, especially if you haven't provided a way to turn it off.

O.k. any thoughts there? What if we didn't make the extensions schema
PUBLIC? Meaning that explicits rights would have to be given for the
extensions to be used by anyone but a super user?

Obviously the initdb switch could also be selective:

I was thinking last week about what I wanted from a packaging system...

1. Add a new column for all system objects, separate from schema: "package". So you would have "core", "tsearch", "ltree", etc. At the very least this lets you manually uninstall a package by searching for and dropping by package-name. Most of what is currently considered "PostgreSQL" would be "core" package I suppose, but you could split out various of the types ("numeric", "text", "internet" etc.) I suppose). Each project in contrib/ would be a package, as would each procedural language.

2. All packages have the following attributes:
 a. Name, description, version number, supplier name/website
b. Installation script, removal script (as functions - obviously they'll need some bootstrapping)/
    We might want hooks for various upgrade functions too.
c. Test function(s) with predictable names (perhaps just test001() test002()). These might be dropp-able for a production deployment. d. A list of dependencies on other packages/versions. This implies some pg_package_is_installed() function perhaps. e. A default search_path to override any user search_path settings (so your package always calls the desired version of foo()). f. Permissions at a package-level, so that a package can be loaded but not installed, or installed but not usable by non-superusers.

3. All packages that ship with the standard PG distribution are:
  a. built by default
  b. installed to a suitable extensions/packages directory.
  c. have install/remove functions
  d. have some semi-standard naming (pgx_...)
  e. have test functions
  f. are documented in the main manuals

From my limited knowledge of the code, none of this should require major surgery except perhaps permissions at the package level and the bootstrapping for installation.

Bootstrapping could consist of nothing more than a set of SQL scripts which set up some temporary tables and create and call the _install() function.

Any of this in the direction that other people were thinking of?

  Richard Huxton
  Archonet Ltd

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to