Why do you need any explicit syntax? If the database is loading an SQL
file as a result of a LOAD MODULE command wouldn't it know to set
whatever internal state it needs to remember that?
--
Greg
On 22 Mar 2009, at 23:11, Andrew Gierth <and...@tao11.riddles.org.uk>
wrote:
"Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
Tom> I doubt that we want to decorate every CREATE statement we've
Tom> got with an optional MODULE clause; to name just one objection,
Tom> it'd probably be impossible to do so without making MODULE a
Tom> fully reserved word.
Tom> What was discussed in the last go-round was some sort of
Tom> state-dependent assignment of a module context. You could
Tom> imagine either
[snip]
Tom> or something along the lines of
Tom> SET current_module = modname;
Tom> CREATE this;
Tom> CREATE that;
Tom> CREATE the_other;
Tom> SET current_module = null;
Tom> which is really more or less the same thing except that it makes
Tom> the state concrete in the form of an examinable variable. In
Tom> either case you'd need to define how the state would interact
Tom> with transactions and errors.
I like the SET version better. As for transactions and errors, I think
that installing a module should be done inside a transaction anyway;
and the usual GUC mechanisms should handle it if it was done using
SET LOCAL, no?
--
Andrew.
--
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
