Re: [GENERAL] CURRENT_TIMESTAMP
От | Bruce Momjian |
---|---|
Тема | Re: [GENERAL] CURRENT_TIMESTAMP |
Дата | |
Msg-id | 200209232041.g8NKfix19001@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [GENERAL] CURRENT_TIMESTAMP (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: [GENERAL] CURRENT_TIMESTAMP
Re: [GENERAL] CURRENT_TIMESTAMP |
Список | pgsql-sql |
Josh Berkus wrote: > I, for one, would judge that the start time of the statement is "during the > execution"; it would only NOT be "during the execution" if it was a value > *before* the start time of the statement. It's a semantic argument. > > The spec is, IMHO, rather vague on how this would relate to transactions. I > do not find it at all inconsitent that Bruce, Thomas, and co. interpreted a > transaction to be an extension of an individual SQL statement for this > purpose (at least, that's what I guess they did). > > Thus, if you accept the postulates that: > 1) "During" a SQL statement includes the start time of the statement, and > 2) A Transaction is the equivalent of a single SQL statement for many > purposes, > Then the current behavior is a logical conclusion. > > Further, we could not change that behaviour without breaking many people's > applications. I don't see how we can defend returning the start of the transaction as the current_timestamp. In a multi-statement transaction, that doesn't seem very current to me. I know there are some advantages to returning the same value for all queries in a transaction, but is that value worth returning such stale time information? -- 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
В списке pgsql-sql по дате отправления: