Re: truncate in combination with deferred triggers - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: truncate in combination with deferred triggers
Date
Msg-id 200609022120.k82LKsB05953@momjian.us
Whole thread Raw
In response to Re: truncate in combination with deferred triggers  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Is this a TODO or is it going to be fixed for 8.2?

---------------------------------------------------------------------------

Tom Lane wrote:
> Stephan Szabo <sszabo@megazone.bigpanda.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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match

--
  Bruce Momjian   bruce@momjian.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

pgsql-bugs by date:

Previous
From: "T.J. Ferraro"
Date:
Subject: Re: BUG #2604: Bug's
Next
From: Bruce Momjian
Date:
Subject: Re: BUG #2599: AM/PM doesn't work in to_timestamp in