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 > > > 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
