Tom Lane <t...@sss.pgh.pa.us> writes: > 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.
Now that you say that my vote goes for ERRORing out as soon as both schema and version are not explicitly given. > 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. I know I did not take any time to think about non-superusers and relative security issues in my patches, but somehow though you had some "magic" bullet here. Baring that, agreed, it's not something to rush in. What I think we could do to solve this particular issue in 9.1 would be for CREATE LANGUAGE to internally create an extension of the same name and with server_version as the version. Long term, we will want to still have a compatibility support for CREATE LANGUAGE to still work, so I think that's a good option here. The version bit, you probably will say something against. Then we could make it '0.' || server_version (so '0.9.1' in fact). And we solve it fully in 9.2 where plpgsql is upgraded to '1.0'. Unless core extensions have the same version as the core product, unlike contrib extensions? So in 9.1 there would be the oddity that to create the plpgsql extension you have to issue CREATE LANGUAGE. But as a result you can set your own extension's control file to require plpgsql. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
