Re: truncate in combination with deferred triggers

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Markus Schiltknecht <markus(at)bluegap(dot)ch>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: truncate in combination with deferred triggers
Date: 2006-08-21 21:44:03
Message-ID: 20060821143934.U31718@megazone.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs


On Mon, 21 Aug 2006, Tom Lane wrote:

> Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> > Yeah, I think there are a few possibilities around truncate inside a
> > savepoint that's rolledback that we have to be careful of.
>
> Yuck :-(
>
> > If we could mark the entries in some way so we knew whether or not they
> > were made obsolete by a truncate of our own tranasaction or a committed or
> > rolled back past subtransaction of ours, we could probably make both of
> > these work nicely.
>
> That seems much more trouble than it's worth, unless someone can
> convince me that this isn't a corner case with little real-world value.
>
> Furthermore, this still doesn't address the worry about whether there
> are cases where dropping the trigger calls would be inappropriate.

I don't believe there are for foreign keys on the referring side since the
post-truncate case is trivially satisfying the constraint, but I can
imagine that there might exist other uses for deferred triggers for which
one might care.

> I propose just having TRUNCATE check for pending triggers on the
> target tables, and throw an error if there are any.

That sounds reasonable to me, although I don't much use truncate in the
first place.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Jim Nasby 2006-08-21 21:55:28 Re: referential integrity violation - key referenced from
Previous Message Tom Lane 2006-08-21 21:12:18 Re: truncate in combination with deferred triggers