Re: contrib function naming, and upgrade issues

Hello

attention, MODULE is ANSI SQL keyword, and modules are class from ANSI SQL.

<SQL-server module definition> ::=
CREATE MODULE <SQL-server module name>
[ <SQL-server module character set specification> ]
[ <SQL-server module schema clause> ] [ <SQL-server module path
specification> ]
[ <temporary table declaration>... ]
<SQL-server module contents>...
END MODULE
<SQL-server module character set specification> ::=
NAMES ARE <character set specification>
<SQL-server module schema clause> ::=
SCHEMA <default schema name>
<default schema name> ::=
<schema name>
<SQL-server module path specification> ::=
<path specification>
<SQL-server module contents> ::=
<SQL-invoked routine> <semicolon>

Regards
Pavel Stehule

2009/3/23 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> 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
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>