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 PostgreSQL itself be a prerequisite, as well as any PL or core extension. I was just going to rely on PostgreSQL release version numbers for all of these. That way, one could specify that pl/pgsql is required in build_requires, for example, to make sure it's there for updates. Does that make sense? Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
