Re: Truncate Triggers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Fetter <david(at)fetter(dot)org>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Decibel! <decibel(at)decibel(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Truncate Triggers
Date: 2008-02-02 19:23:40
Message-ID: 9031.1201980220@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Fetter <david(at)fetter(dot)org> writes:
> On Thu, Jan 31, 2008 at 10:22:42AM +0000, Gregory Stark wrote:
>> There are plenty of DDL commands which modify data (CREATE INDEX,
>> ATLER TABLE ALTER COLUMN TYPE). The defining characteristic of DDL
>> is not that it doesn't modify the data but that it does modify the
>> table definition.

> Counter-example: ALTER TABLE ALTER COLUMN USING will almost certainly
> modify data, but it's DDL nonetheless.

Uh, how is that a counter-example to what Greg said?

I think the real question here is whether there is a defensible use-case
for a trigger. In the case of TRUNCATE it's pretty obvious what you
might want the trigger for: to do the same thing your per-row ON DELETE
trigger does, but across all rows. It's much less easy to envision a
scriptable-in-advance response to arbitrary ALTER TABLE operations.

Looked at in this light, TRUNCATE is clearly more nearly DML than DDL,
in the sense that its effects are predictable and involve only the data
not the schema (at least in the user's view).

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian G. Pflug 2008-02-02 19:24:27 Re: configurability of OOM killer
Previous Message Tom Lane 2008-02-02 19:15:48 Re: configurability of OOM killer