Re: [HACKERS] Usability tweaks for extension commands
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
Re: [HACKERS] Usability tweaks for extension commands
Tom Lane t...@sss.pgh.pa.us writes: ERROR: version to install or update to must be different from old version On reflection it seems like this is overly paranoid, and it'd be more useful if the ALTER just reported a NOTICE along the lines of version so-and-so is already installed. Any objections? I see that's too late, but FWIW, +1 :) Another thought is that it'd probably be useful for there to be a CREATE OR REPLACE EXTENSION syntax, with the behavior of install the extension if it's not present, else make sure it's of the specified or default version; this behavior parallels CREATE OR REPLACE LANGUAGE which is something we've been refining for awhile. I am not however entirely sure what to do with the SCHEMA option if the extension already exists --- we might be able to do SET SCHEMA, but perhaps that's too aggressive. Thoughts? By all means, let's learn from our history. +1. I would expect CORE to be able to change things in the database, so I would vote for doing the SET SCHEMA here if needed. But if we do that, then certainly we should also automatically handle upgrades too when possible, right? That would be very useful, so still +1. 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
Re: [HACKERS] Usability tweaks for extension commands
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
[HACKERS] Usability tweaks for extension commands
Currently, ALTER EXTENSION UPDATE throws an error if there's nothing to do: regression=# create extension adminpack ; CREATE EXTENSION regression=# alter extension adminpack update; ERROR: version to install or update to must be different from old version On reflection it seems like this is overly paranoid, and it'd be more useful if the ALTER just reported a NOTICE along the lines of version so-and-so is already installed. Any objections? Another thought is that it'd probably be useful for there to be a CREATE OR REPLACE EXTENSION syntax, with the behavior of install the extension if it's not present, else make sure it's of the specified or default version; this behavior parallels CREATE OR REPLACE LANGUAGE which is something we've been refining for awhile. I am not however entirely sure what to do with the SCHEMA option if the extension already exists --- we might be able to do SET SCHEMA, but perhaps that's too aggressive. Thoughts? 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
Re: [HACKERS] Usability tweaks for extension commands
On Feb 15, 2011, at 5:18 PM, Tom Lane wrote: Currently, ALTER EXTENSION UPDATE throws an error if there's nothing to do: regression=# create extension adminpack ; CREATE EXTENSION regression=# alter extension adminpack update; ERROR: version to install or update to must be different from old version On reflection it seems like this is overly paranoid, and it'd be more useful if the ALTER just reported a NOTICE along the lines of version so-and-so is already installed. Any objections? Makes sense to me. Another thought is that it'd probably be useful for there to be a CREATE OR REPLACE EXTENSION syntax, with the behavior of install the extension if it's not present, else make sure it's of the specified or default version; this behavior parallels CREATE OR REPLACE LANGUAGE which is something we've been refining for awhile. I am not however entirely sure what to do with the SCHEMA option if the extension already exists --- we might be able to do SET SCHEMA, but perhaps that's too aggressive. This one is a bit over my head, alas. David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
