Tom Lane wrote:
> Neil Conway <neilc@samurai.com> 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 pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
