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 <t...@sss.pgh.pa.us>: > Robert Haas <robertmh...@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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers