On Feb 16, 2011, at 3:00 PM, Tom Lane wrote:
> According to our prior discussions of C.O.R. commands, the general
> principle that such a command ought to follow is that upon success,
> the object exists with exactly the properties implied by the command's
> arguments. So (1) if the extension isn't in the stated or default
> schema, we must move it there, or report failure if we can't;
> (2) if it's not of the stated or default version, we must update to that
> version, or fail if we can't. That seems straightforward enough,
> I'm just wondering whether applying that theory is leading to the
> right choices here. In particular, the default behavior if you didn't
> say "SCHEMA something" would be to automatically move the extension
> into whatever random schema happens to be the front of your search_path,
> which might well not be what you intended. Maybe it would be safer to
> not do a move on the basis of a defaulted schema selection.
Would it not be put into the schema with which the extension was associated?
> Anyway, I think this is all 9.2 material. I brought it up when I was
> wondering if there were a chance of making CREATE LANGUAGE translate
> into a CREATE EXTENSION operation for 9.1. I've since given that up,
> after realizing that we are nowhere near the point where we'd be able
> to allow non-superusers to execute CREATE EXTENSION. The permissions
> and security implications are too complicated to rush through.
For the PGXN client, I was planning to allow, in addition to extension versions, one could specify that a version of
PostgreSQLitself be a prerequisite, as well as any PL or core extension. I was just going to rely on PostgreSQL release
versionnumbers for all of these. That way, one could specify that pl/pgsql is required in build_requires, for example,
tomake sure it's there for updates.
Does that make sense?
Best,
David