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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
