Dimitri Fontaine wrote: > 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.
This discussion is sounding very design-ish, which makes me think we should just leave things unchanged for 9.0 and have external regression test designers work around this problem in their Makefiles, as Alvaro suggested. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
