Re: contrib function naming, and upgrade issues

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: contrib function naming, and upgrade issues
Date: 2009-03-23 03:11:08
Message-ID: 87hc1lvsqb.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> "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

Responses

Browse pgsql-hackers by date

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