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

Dimitri Fontaine <dfontaine(at)hi-media(dot)com> writes:
> Not sure how helpful I'll be there, but I can't help placing the
> extension's proposal again.

> If we had extensions here, plpgsql would be a core maintained extension,
> made available by CREATE EXTENSION in the database (which initdb would
> do in templates), then have the language installed by means of issuing
> an INSTALL EXTENSION command.

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.

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.

However it still leaves us with the problem that CINE is underspecified.
In particular, since we have already got the notion that languages have
owners and ACLs, I'm unsure what the desired state is when pg_dump tries
to set the owner and/or ACL for a pre-existing language. I know what
is likely to happen if we just drop these concepts into the existing
system: restoring a dump will take away ownership from whoever installed
the language (extension) previously. That doesn't seem very good,
especially if the ownership of any SQL objects contained in the
extension doesn't change.

regards, tom lane