Re: contrib function naming, and upgrade issues

Hi,

Heard about http://wiki.postgresql.org/wiki/ExtensionPackaging ? :)

Le 22 mars 09 à 14:29, Dave Page a écrit :
>> - want to be able to do INSTALL PACKAGE foo; without needing to
>> mess with .sql files. This might default to looking for
>> $libdir/foo.so, or there might be a mechanism to register packages
>> globally or locally.

Part of the proposal.

>> - want to be able to do INSTALL PACKAGE foo VERSION 1; and get
>> the version 1 API rather than whatever the latest is.

To be added to the proposal.

>> - want to be able to do INSTALL PACKAGE foo SCHEMA bar; rather
>> than having to edit some .sql file.

Part of the proposal (install time variables/options/parameters).

>> - want to be able to do DROP PACKAGE foo;

Part of the proposal.

>> - want pg_dump to not output the definitions of any objects that
>> belong to a package, but instead to output an INSTALL PACKAGE foo
>> VERSION n SCHEMA x;

Part of the proposal.

> I think using PACKAGE is a bad idea as it'll confuse people used to
> Oracle. MODULE perhaps?

Using package would tie us into supporting oracle syntax, which nobody
actually wants, it seems. Or at least we have to reserve the keyword
for meaning "oracle compliant facility".

Module on the other hand is already used in PostgreSQL to refer to the
dynamic lib you get when installing C coded extensions (.so or .dll),
what we miss here is a way to refer to them in pure SQL, have their
existence cared about in the catalogs. That's the part Tom Dunstan
worked on IIRC.
He also worked out some OS level tools for module handling, but I
think I'd prefer to have another notion in between, the extension.

The extension would be a new SQL object referring to zero, one or more
modules and one or more SQL scripts creating new SQL objects (schemas,
tables, views, tablespaces, functions, types, casts, operator classes
and families, etc, whatever SQL scripting we support now --- yes,
index am would be great too). Those would depend (pg_depend) on the
package SQL object. I don't think we need to be able to nest a package
creation inside the package SQL scripts, but hey, why not.

So my vote is for us to talk about modules (.so) and extensions (the
packaging and distribution of them). And this term isn't even new in
PostgreSQL glossary ;)

Regards,
--
dim