Re: start of transaction (was: Re: [PERFORM] Help with count(*))
От | Tom Lane |
---|---|
Тема | Re: start of transaction (was: Re: [PERFORM] Help with count(*)) |
Дата | |
Msg-id | 3798.1069027704@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | start of transaction (was: Re: [PERFORM] Help with count(*)) (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: start of transaction (was: Re: [PERFORM] Help with count(*))
Re: start of transaction (was: Re: [PERFORM] Help with |
Список | 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 по дате отправления: