| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | Alex Pilosov <alex(at)pilosoft(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: time stops within transaction |
| Date: | 2000-10-18 16:39:29 |
| Message-ID: | 5243.971887169@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2000-10-18 17:20:38 | Coming attractions: VPATH build; make variables issue |
| Previous Message | Peter Eisentraut | 2000-10-18 16:10:04 | Re: time stops within transaction |