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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
