Re: feature proposal - triggers by semantics

Поиск
Список
Период
Сортировка
От Christopher Browne
Тема Re: feature proposal - triggers by semantics
Дата
Msg-id CAFNqd5XoQUV98_rkBWJj5KigzDai8NZg1Bnv=tdChnUiXhaR1w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: feature proposal - triggers by semantics  (Darren Duncan <darren@darrenduncan.net>)
Список pgsql-hackers
On Thu, Nov 15, 2012 at 2:53 PM, Darren Duncan <darren@darrenduncan.net> wrote:
> I still think the syntax of TRUNCATE FOR EACH ROW would be useful, but if no one agrees...

I'm compelled to disagree.

What was useful about TRUNCATE in the first place was that it quickly operated against the entire table.

If you want to change that to row-by-row processing, then it is actually a little bit worse than
DELETE FROM some_table, in that it is introducing an irregularity in language that no longer
provides any corresponding benefit.  (e.g. - such as that TRUNCATE is fast).

If you want to be certain of doing row-by-row processing, then the better answer is to:
a) Use DELETE instead in your application, and
b) Put a guard on to prevent using TRUNCATE.  (e.g. - attach triggers that react to TRUNCATE with "go away, don't bother me!")

I observe that the Slony replication system initially implemented that 'guard' approach when TRUNCATE
triggers were first provided, until we came up with a suitable strategy to capture and replicate the
TRUNCATE request.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

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

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: tuplesort memory usage: grow_memtuples
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Dumping an Extension's Script