Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 56A532E4733 for ; Thu, 10 Jan 2008 14:09:02 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 62005-03-4 for ; Thu, 10 Jan 2008 14:08:56 -0400 (AST) Received: from mail.fmed.uba.ar (mail.fmed.uba.ar [157.92.152.1]) by postgresql.org (Postfix) with ESMTP id 8F04D2E48D9 for ; Thu, 10 Jan 2008 14:08:55 -0400 (AST) Received: from [157.92.155.58] (mailbis [157.92.155.58]) by mail.fmed.uba.ar (Postfix) with ESMTP id E825C11CB41; Thu, 10 Jan 2008 16:09:05 -0200 (ARST) Message-ID: <47865FFA.6060008@fmed.uba.ar> Date: Thu, 10 Jan 2008 15:12:10 -0300 From: Gerardo Herzig User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Lane CC: Alvaro Herrera , Pavel Stehule , Chris Browne , pgsql-sql@postgresql.org Subject: Re: trigger for TRUNCATE? References: <4783BEA9.3020507@fmed.uba.ar> <60tzloyr0u.fsf@dba2.int.libertyrms.com> <162867790801081338n237497efpecffaa255253274d@mail.gmail.com> <47864A6B.3070902@fmed.uba.ar> <20080110171027.GK6465@alvh.no-ip.org> <8003.1199986734@sss.pgh.pa.us> In-Reply-To: <8003.1199986734@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200801/72 X-Sequence-Number: 29925 Tom Lane wrote: >Alvaro Herrera 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