Re: [GENERAL] Updating column on row update

Поиск
Список
Период
Сортировка
От Thom Brown
Тема Re: [GENERAL] Updating column on row update
Дата
Msg-id bddc86150911230118o62a0326crddeb37ce71d3c602@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [GENERAL] Updating column on row update  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [GENERAL] Updating column on row update
Список pgsql-hackers
2009/11/23 Tom Lane <tgl@sss.pgh.pa.us>
CREATE OR REPLACE has got far safer semantics from the viewpoint of a
script that wants to bull through without having any actual error
handling (which is more or less the scenario we are arguing here, no?)
After successful execution of the command you know exactly what
properties the object has got.

Whether it would be sensible to have CREATE OR REPLACE semantics for a
language is something I'm not very clear on.  It seems like changing any
of the properties of a pg_language entry could be rather fatal from the
viewpoint of an existing function using the language.

[ thinks for awhile... ]  Actually, CREATE LANGUAGE is unique among
creation commands in that the common cases have no parameters, at least
not since we added pg_pltemplate.  So you could imagine defining CINE
for a language as disallowing any parameters and having these semantics:
       * language not present -> create from template
       * language present, matches template -> OK, do nothing
       * language present, does not match template -> report error
This would meet the objection of not being sure what the state is
after successful execution of the command.  It doesn't scale to any
other object type, but is it worth doing for this one type?

                       regards, tom lane

Actually, I prefer CREATE OR REPLACE over CINE, at least for the majority of the creations, especially since it would be more consistent with what we have for functions.  If there must be an exception for languages, it would make sense from what you describe above.

As for having plpgsql installed by default, are there any security implications?  If not, I can only see it as an advantage.  At the moment we're having to resort to a bit of a hack using a CASE statement in a plain SQL function as mentioned earlier in this thread.

Thom

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: named generic constraints [feature request]
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Partitioning option for COPY