Re: contrib function naming, and upgrade issues - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: contrib function naming, and upgrade issues
Date
Msg-id 87hc1lvsqb.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: contrib function naming, and upgrade issues  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: contrib function naming, and upgrade issues  (Greg Stark <greg.stark@enterprisedb.com>)
List pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> I doubt that we want to decorate every CREATE statement we'veTom> got with an optional MODULE clause; to name just
oneobjection,Tom> it'd probably be impossible to do so without making MODULE aTom> fully reserved word.
 
Tom> What was discussed in the last go-round was some sort ofTom> state-dependent assignment of a module context.  You
couldTom>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 makesTom> the state concrete in the form of an
examinablevariable.  InTom> either case you'd need to define how the state would interactTom> 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.


pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: contrib function naming, and upgrade issues
Next
From: Greg Stark
Date:
Subject: Re: contrib function naming, and upgrade issues