Skip site navigation (1) Skip section navigation (2)

Re: trigger for TRUNCATE?

From: Erik Jones <erik(at)myemma(dot)com>
To: Richard Huxton <dev(at)archonet(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 16:01:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-sql
On Jan 11, 2008, at 2:24 AM, Richard Huxton wrote:

> 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
>> 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>

Not that DDL statement triggers wouldn't be just as useful for  

Erik Jones

DBA | Emma®
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at

In response to

pgsql-sql by date

Next:From: Simon RiggsDate: 2008-01-11 16:41:40
Subject: Re: trigger for TRUNCATE?
Previous:From: Pavel StehuleDate: 2008-01-11 14:17:53
Subject: Re: SQL stored function inserting and returning data in a row.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group