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
Re: time stops within transaction Re: time stops within transaction |
| Список | 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 по дате отправления: