Tom Lane wrote: > Neil Conway <[EMAIL PROTECTED]> writes: > > Hmmm... I agree this behavior isn't ideal, although I can see the case > > for viewing this as a mistake by the application developer: they are > > assuming that they know exactly when transactions begin, which is not > > a feature provided by their language interface. > > Well, actually, it's a bug in the interface IMHO. But as I said in the > last thread, it's a fairly widespread bug. We've been taking the > position that the interface libraries should get fixed, and that's not > happening. It's probably time to look at a server-side fix. > > > If we do change this, I think Dennis' idea of making now() always > > return the same value within a given transaction is interesting: > > You mean the time of the first now() call? I thought that was an > interesting idea also, but it's probably not going to look so hot > when we complete the TODO item of adding access to > the start-of-current-statement time. Having start-of-transaction be > later than start-of-statement isn't gonna fly :-(. If we were willing > to abandon that TODO item then I'd be interested in defining now() as > Dennis suggested.
Defining now() as the first call seems pretty arbitrary to me. I can't think of any time-based interface that has that API. And what if a trigger called now() in an earlier query and you didn't even know about it. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
