| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | 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-10 17:38:54 |
| Message-ID: | 8003.1199986734@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Gerardo Herzig escribi:
>> Yes, the TRUNCATE statement is not sql ansi, maybe is a more low level
>> thing than i think.
> TRUNCATE currently does not fire triggers, but that doesn't mean it's
> impossible to do it. I think it would be fairly easy to add support
> for that.
The entire point of TRUNCATE is to not do a table scan, so making it
fire per-row triggers seems pretty misguided to me.
We could maybe make it fire per-statement ON DELETE triggers, but
there's a future-proofing pitfall in that: someday it'd be nice
for statement-level triggers to have access to the set of deleted rows,
and then you'd be stuck either scanning the table or having TRUNCATE
act differently from plain DELETE.
My feeling is that if you want to know what was deleted, you shouldn't
use TRUNCATE.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2008-01-10 17:47:05 | Re: trigger for TRUNCATE? |
| Previous Message | Alvaro Herrera | 2008-01-10 17:10:27 | Re: trigger for TRUNCATE? |