Re: Modifying and solidifying contrib

Joshua D. Drake wrote:
> Tom Lane wrote:
>> "Joshua D. Drake" <jd(at)commandprompt(dot)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. 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