Re: contrib function naming, and upgrade issues

On Sun, Mar 22, 2009 at 10:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> ...  I suspect that it's going to boil down to running a
>> SQL script, which will need to somehow get that module installed.  To
>> make that work, I think we need "CREATE MODULE foo" and then "CREATE
>> <TABLE|VIEW|FUNCTION|...> ... MODULE foo".  So the SQL script will
>> create the module and then create all of the objects and make them
>> depend on the module using the optional "MODULE foo" clause.
>
> I doubt that we want to decorate every CREATE statement we've got with
> an optional MODULE clause; to name just one objection, it'd probably
> be impossible to do so without making MODULE a fully reserved word.
>
> What was discussed in the last go-round was some sort of state-dependent
> assignment of a module context.  You could imagine either
>
>        BEGIN MODULE modname;
>
>        CREATE this;
>        CREATE that;
>        CREATE the_other;
>
>        END MODULE;
>
> or something along the lines of
>
>        SET current_module = modname;
>
>        CREATE this;
>        CREATE that;
>        CREATE the_other;
>
>        SET current_module = null;
>
> which is really more or less the same thing except that it makes the
> state concrete in the form of an examinable variable.  In either case
> you'd need to define how the state would interact with transactions
> and errors.

I thought about that, but wasn't sure if people would like it, since
it seems a little un-SQL-ish. But I'm fine with it, and it has the
additional advantage that it avoids the need to recapitulate the
module name many times. If there's no semantic problem with making
current_module be a GUC, the SET syntax seems very tempting, since it
avoids the need to make up something new and different.

...Robert