From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Gerardo Herzig <gherzig(at)fmed(dot)uba(dot)ar>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: trigger for TRUNCATE? |
Date: | 2008-01-11 08:24:35 |
Message-ID: | 478727C3.3090301@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> My thinking is that a TRUNCATE trigger is a per-statement trigger which
>> doesn't have access to the set of deleted rows (Replicator uses it that
>> way -- we replicate the truncate action, and replay it on the replica).
>> In that way it would be different from a per-statement trigger for
>> DELETE.
>
> Ah, right. I was thinking in terms of having TRUNCATE actually fire the
> existing ON DELETE-type triggers, but that's not really helpful --- you'd
> need a separate trigger-event type. So we could just say by fiat that
> an ON TRUNCATE trigger doesn't get any rowset information, even after we
> add that for the other types of statement-level triggers.
I've always considered TRUNCATE to be DDL rather than DML. I mentally
group it with DROP TABLE rather than DELETE>
--
Richard Huxton
Archonet Ltd
From | Date | Subject | |
---|---|---|---|
Next Message | Gerardo Herzig | 2008-01-11 11:03:07 | Re: SQL stored function inserting and returning data in a row. |
Previous Message | Rajesh Kumar Mallah | 2008-01-11 07:20:13 | Re: (possible) bug with constraint exclusion |