Re: [GENERAL] CURRENT_TIMESTAMP
От | Bruce Momjian |
---|---|
Тема | Re: [GENERAL] CURRENT_TIMESTAMP |
Дата | |
Msg-id | 200209240037.g8O0bwM14523@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [GENERAL] CURRENT_TIMESTAMP (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [GENERAL] CURRENT_TIMESTAMP
Re: [GENERAL] CURRENT_TIMESTAMP |
Список | pgsql-sql |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I see what you are saying now --- that even single user statements can > > trigger multiple statements, so you would have to say transaction start > > time is time the user query starts. I can see how that seems a little > > arbitrary. However, don't we have separate paths for user queries and > > queries sent as part of a rule? > > We could use "time of arrival of the latest client command string", > if we wanted to do something like this. My point is that that very > arbitrarily assumes that those are the significant points within a > transaction, and that the client has no need to send multiple commands > that want to insert the same timestamp into different tables. This is > an unwarranted assumption about the client's control structure, IMHO. > > A possible compromise is to dissociate now() and current_timestamp, > allowing the former to be start of transaction and the latter to be > start of client command. I was thinking 'transaction_timestamp' for the transaction start time, and current_timestamp for the statement start time. I would equate now() with current_timestamp. -- 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 по дате отправления: