Neil Conway wrote:
> Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> >> The most common complaint that I recall is that current_timestamp
> >> returns the transaction timestamp rather than the statement timestamp,
> >> which is what many expect. How does your patch address that?
> >
> > No, we believe the standard requires it.
>
> My copy of SQL 200n has the following to say:
>
> Annex C, paragraph 16:
>
> "The time of evaluation of the CURRENT_DATE, CURRENT_TIME, and
> CURRENT_TIMESTAMP functions during the execution of an
> SQL-statement is implementation-dependent."
>
> 6.31, <datetime value function>:
>
> (1) The <datetime value function>s CURRENT_DATE, CURRENT_TIME,
> and CURRENT_TIMESTAMP respectively return the current date,
> current time, and current timestamp; the time and timestamp values
> are returned with time zone displacement equal to the current
> default time zone displacement of the SQL-session. [...]
>
> (2) Let S be an <SQL procedure statement> that is not generally
> contained in a <triggered action>. All <datetime value function>s
> that are contained in <value expression>s that are generally
> contained, without an intervening <routine invocation> whose subject
> routines do not include an SQL function, either in S without an
> intervening <SQL procedure statement> or in an <SQL procedure
> statement> contained in the <triggered action> of a trigger
> activated as a consequence of executing S, are effectively evaluated
> simultaneously. The time of evaluation of a <datetime value
> function> during the execution of S and its activated triggers is
> implementation-dependent.
OK, so we just decided transaction timestamp is the most logical value
for CURRENT_TIMESTAMP. Anyway, this might mean we should have
transaction_timestamp for completeness. Not sure.
--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com
+ If your life is a hard drive, Christ can be your backup. +
