Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
