>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

In response to

• Re: contrib function naming, and upgrade issues at 2009-03-23 02:25:40 from Tom Lane

Responses

• Re: contrib function naming, and upgrade issues at 2009-03-23 03:26:03 from Greg Stark

pgsql-hackers by date

Next:	From: Greg Stark	Date: 2009-03-23 03:26:03
	Subject: Re: contrib function naming, and upgrade issues
Previous:	From: Andrew Gierth	Date: 2009-03-23 03:05:04
	Subject: Re: contrib function naming, and upgrade issues