Re: time stops within transaction

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: Raw Message | Whole Thread | 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

In response to

Responses

Browse pgsql-hackers by date

  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