Re: contrib function naming, and upgrade issues

On Mon, Mar 23, 2009 at 7:46 AM, Dimitri Fontaine
<dfontaine(at)hi-media(dot)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