Re: start of transaction (was: Re: [PERFORM] Help with count(*)) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: start of transaction (was: Re: [PERFORM] Help with count(*))
Date
Msg-id 3798.1069027704@sss.pgh.pa.us
Whole thread Raw
In response to start of transaction (was: Re: [PERFORM] Help with count(*))  (Neil Conway <neilc@samurai.com>)
Responses Re: start of transaction (was: Re: [PERFORM] Help with count(*))  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: start of transaction (was: Re: [PERFORM] Help with  (Hannu Krosing <hannu@tm.ee>)
List pgsql-hackers
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: start of transaction (was: Re: [PERFORM] Help with count(*))
Next
From: Bruce Momjian
Date:
Subject: Re: start of transaction (was: Re: [PERFORM] Help with count(*))