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