Re: time stops within transaction

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: time stops within transaction
Дата
Msg-id 5243.971887169@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: time stops within transaction  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: time stops within transaction  (Peter Eisentraut <peter_e@gmx.net>)
Re: time stops within transaction  (Don Baccus <dhogaza@pacifier.com>)
Re: time stops within transaction  (Alex Pilosov <alex@pilosoft.com>)
Список pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> Au contraire, if it did not behave that way it would violate the spec.
>> See SQL92 6.8 general rule 3:
>> 
>> 3) If an SQL-statement generally contains more than one reference
>> to one or more <datetime value function>s, then all such ref-
>> erences are effectively evaluated simultaneously. The time of
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> evaluation of the <datetime value function> during the execution
>> of the SQL-statement is implementation-dependent.

> statement != transaction

So?  It also says that the choice of exactly when to evaluate now()
is implementation-dependent.  Doing so at start of transaction is
an allowed behavior AFAICS.  Actually calling time(2) at each use
of now(), which is what the original poster seemed to want, is
clearly *not* an allowed behavior.

I think what you are advocating is recomputing now() at each statement
boundary within a transaction, but that's not as simple as it looks
either.  Consider statement boundaries in an SQL function --- the
function is probably being called from some outer statement, so
advancing now() within the function would violate the spec constraint
with respect to the outer statement.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: toast operations while locking a buffer
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Coming attractions: VPATH build; make variables issue