Added to TODO:
o Fix problem when cascading referential triggers make changes on
cascaded tables, seeing the tables in an intermediate state
http://archives.postgresql.org/pgsql-hackers/2005-09/msg00174.php
http://archives.postgresql.org/pgsql-hackers/2005-09/
On Friday 09 September 2005 08:46, Stephan Szabo wrote:
> On Fri, 9 Sep 2005, Tom Lane wrote:
> > Stephan Szabo <[EMAIL PROTECTED]> writes:
> > > Is there a case other than a before trigger updating a row we will want
> > > to act upon later in the statement where we'll get a row with xmax of
> > >
On Fri, 9 Sep 2005, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > Is there a case other than a before trigger updating a row we will want to
> > act upon later in the statement where we'll get a row with xmax of our
> > transaction and cmax greater than the current command?
>
> T
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Is there a case other than a before trigger updating a row we will want to
> act upon later in the statement where we'll get a row with xmax of our
> transaction and cmax greater than the current command?
The greater-cmax case could occur via any kind of
On Fri, 2 Sep 2005, Stephan Szabo wrote:
> [Hackers now seems more appropriate]
>
> On Thu, 1 Sep 2005, Stephan Szabo wrote:
>
> >
> > On Tue, 23 Aug 2005, Stephan Szabo wrote:
> >
> > > Here's my current work in progress for 8.1 devel related to fixing the
> > > timing issues with referential act
[Hackers now seems more appropriate]
On Thu, 1 Sep 2005, Stephan Szabo wrote:
>
> On Tue, 23 Aug 2005, Stephan Szabo wrote:
>
> > Here's my current work in progress for 8.1 devel related to fixing the
> > timing issues with referential actions having their checks run on
> > intermediate states.
