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@sss.pgh.pa.us>:
> Robert Haas <robertmhaas@gmail.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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
