On Mon, 23 Sep 2002 13:05:42 -0400, Tom Lane <tgl@sss.pgh.pa.us>
wrote:
>Manfred Koizar <mkoi-pg@aon.at> writes:
>> This has been discussed before and I know I'm going to get flamed for
>> this, but IMHO having now() (which is a synonym for CURRENT_TIMESTAMP)
>> return the start time of the current transaction is a bug, or at least
>> it is not conforming to the standard.
>
>As you say, it's been discussed before.
Yes, and I hate to be annoying.
>We concluded that the spec defines the behavior as
>implementation-dependent,
AFAICT the spec requires the returned value to meet two conditions.
C1: If a statement contains more than one <datetime value function>,
they all have to return (maybe different formats of) the same value.
C2: The returned value has to represent a point in time *during* the
execution of the SQL-statement.
The only thing an implementor is free to choose is which point in time
"during the execution of the SQL-statement" is to be returned, i.e. a
timestamp in the interval between the start of the statement and the
first time when the value is needed.
The current implementation only conforms to C1.
>and therefore we can pretty much do what we want.
Start time of the statement, ... of the transaction, ... of the
session, ... of the postmaster, ... of the century?
I understand that with subselects, functions, triggers, rules etc. it
is not easy to implement the specification. If we can't do it now, we
should at least add a todo and make clear in the documentation that
CURRENT_DATE/TIME/TIMESTAMP is not SQL92/99 compliant.
Servus
Manfred
