From: | Gerardo Herzig <gherzig(at)fmed(dot)uba(dot)ar> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, 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 18:12:10 |
Message-ID: | 47865FFA.6060008@fmed.uba.ar |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Tom Lane wrote:
>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
>
>
>
I 100% agree, i can live using delete instead, but i can't ensure the
whole team i work with will not use TRUNCATE. It was my bad naming the
thread with such a contradictory name, im just looking the way to
capture it in any form. I would even consider the posibility of
*ignoring* a TRUNCATE command, if thats possible.
Thanks you all, dudes!
Gerardo
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-01-10 19:15:24 | Re: trigger for TRUNCATE? |
Previous Message | Alvaro Herrera | 2008-01-10 17:47:05 | Re: trigger for TRUNCATE? |