Re: contrib function naming, and upgrade issues

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.

regards, tom lane