Tom Lane <t...@sss.pgh.pa.us> writes: > Well, that isn't really going to help us in terms of what to do for 9.0. > But the possibility that something like this might happen in future is > one thing that makes me hesitant about extending CREATE LANGUAGE right > now --- the more bells and whistles we put on it, the harder it will be > to have a clean upgrade to an EXTENSION facility.
Agreed, but we could still evolve the command with keeping an eye on the future. As of now I intend to implement what's on this page: http://wiki.postgresql.org/wiki/ExtensionPackaging So maybe a quick glance then some early design approval would make it possible to change the CREATE LANGUAGE in an EXTENSION compatible way. > One thing that strikes me about your proposal is that INSTALL EXTENSION > doesn't sound like a CREATE OR REPLACE operation. It sounds like a > CREATE IF NOT EXISTS operation, because there simply is not a guarantee > that what gets installed is exactly what the user expected --- in > particular, for pg_dump, it isn't guaranteeing that the new version's > extension is exactly like what was in the old database. And that's not > a bad thing, in this context; it's more or less the Whole Point. In fact it's not either one or the other, because the CREATE EXTENSION is providing the meta data, which includes an optional upgrade function. So if you INSTALL EXTENSION over an existing one, and meantime you've been installing the new version (file system install, PGAN or distro packaged or source level install; then the new CREATE EXTENSION which should be given in the foo.sql for the foo EXTENSION), in this case it's an upgrade, and what INSTALL EXTENSION is meant to do is run the upgrade function with as arguments current and new version numbers. It's when the EXTENSION is not providing this upgrade function that the behavior is more CREATE OR REPLACE, because it'd then run the installation script all over again. In case you provided an upgrade function, we're yet to see how to provide facilities to the extensions authors in order to easily address the columns of their data type and the indexes from their operator classes, etc. 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