Re: Modifying and solidifying contrib

Joshua D. Drake wrote:
> Tom Lane wrote:
>> "Joshua D. Drake" <jd@commandprompt.com> 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.
Installationscript, removal script (as functions - obviously 
 
they'll need some bootstrapping)/    We might want hooks for various upgrade functions too. c. Test function(s) with
predictablenames (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
loadedbut 
 
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/packagesdirectory.  c. have install/remove functions  d. have some semi-standard naming (pgx_...)  e. have
testfunctions  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