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

Dimitri Fontaine wrote:
> 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.

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 <bruce(at)momjian(dot)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. +