On Mon, Mar 23, 2009 at 7:46 AM, Dimitri Fontaine <dfonta...@hi-media.com> wrote: > On Monday 23 March 2009 12:34:31 Robert Haas wrote: >> That might not be the only time you ever want to create dependencies >> on the module object. What if the module wants to create an >> additional table, view, etc. at some later time, following the load? >> I'm not sure whether there's a use case for that, but it doesn't seem >> totally implausible. > > Then there's Tom's idea of SET module TO ...; to have the context handy, or a > WIP syntax in http://wiki.postgresql.org/wiki/ExtensionPackaging > > CREATE OR REPLACE EXTENSION foo ... > AS $$ > $$; > > So you could REPLACE an existing extension and add whatever you need to.
I think SET module_context = 'whatever' is the right idea. CREATE OR REPLACE MODULE is not going to work. Suppose that when we originally install the extension we do: CREATE TABLE some_table (id integer not null, foo text not null, primary key (id)); ...later when we try to do CREATE OR REPLACE the definition has changed to: CREATE TABLE some_table (id integer not null, bar text not null, baz text not null, primary key (id)); It may well be that the table has data in it that was inserted after module creation time, and the user may want it preserved with the upgrade, but there's really no way to even begin to guess what the user had in mind here. The CREATE OR REPLACE idea doesn't have very clean semantics even with functions, which are probably the primary use case for this mechanism. If I replace a module, and the new definition doesn't define one of the functions in the original definition, does that amount to an implicit drop of that function? If the module contains a CREATE FUNCTION command, does using CREATE OR REPLACE on the module effectively turn CREATE FUNCTION into CREATE OR REPLACE FUNCTION? Nobody is going to like these semantics, I think, and it gets far uglier when you start looking at tables, views, etc. (It's also worth noting, as an independent point, that I suspect SET module_context = 'whatever' will be easier to implement.) ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
