Dimitri Fontaine <dfonta...@hi-media.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers