Re: start of transaction (was: Re: [PERFORM] Help with count(*))

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