Re: contrib function naming, and upgrade issues

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: contrib function naming, and upgrade issues
Дата
Msg-id 87hc1lvsqb.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: contrib function naming, and upgrade issues  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: contrib function naming, and upgrade issues
Список 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 по дате отправления:

Предыдущее
От: Andrew Gierth
Дата:
Сообщение: Re: contrib function naming, and upgrade issues
Следующее
От: Greg Stark
Дата:
Сообщение: Re: contrib function naming, and upgrade issues