From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
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:12:18 |
Message-ID: | 19994.1156194738@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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 propose just having TRUNCATE check for pending triggers on the
target tables, and throw an error if there are any.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2006-08-21 21:44:03 | Re: truncate in combination with deferred triggers |
Previous Message | Stephan Szabo | 2006-08-21 20:43:58 | Re: truncate in combination with deferred triggers |