Re: PGXS: REGRESS_OPTS=--load-language=plpgsql

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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