On Friday 09 September 2005 08:46, Stephan Szabo wrote:
> On Fri, 9 Sep 2005, Tom Lane wrote:
> > Stephan Szabo <sszabo@megazone.bigpanda.com> 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 function, not only a
> > trigger, ie
> >
> > update tab set x = foo(x) where ...
> >
> > where foo() is a volatile function that internally updates the tab
> > table.
>
> I *thought* I was missing a case, I just couldn't figure out what.
>
> > I suppose you could say that this is horrible programming practice and
> > anyone who tries it deserves whatever weird behavior ensues ... but
> > it's not the case that every such situation involves a trigger.
>
> Well, the change I was thinking of would have made it an error if foo(x)
> updated a row that was then later selected by the update rather than the
> current behavior which I think would have ignored the already updated row,
> so that's probably not going to work.

I see that this still is not addressed fulling in beta 3. Can anybody give a
quick overview of where this is sitting, and if it's likely to make it's way
into 8.1 gold ?

>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq

--
Darcy Buskermolen
Wavefire Technologies Corp.

http://www.wavefire.com
ph: 250.717.0200
fx: 250.763.1759

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster