Neil Conway wrote:
> Bruce Momjian wrote:
> > <function>CURRENT_TIMESTAMP</> might not be the
> > transaction start time on other database systems.
> > For this reason, and for completeness,
> > <function>transaction_timestamp</> is provided.
>
> Well, transaction_timestamp() is even more unlikely to be the
> transaction start time on other database systems :) If the user wants
> non-standard syntax for getting the timestamp at which the current
> transaction began, we already have now().
True, which is why I brought it up. I think a good argument can be made
that we don't need two non-standard ways of specifying the transaction
timestamp, but we need to decide that as a group.
> > One trick is that these should be the same:
> >
> > test=> SELECT statement_timestamp(), transaction_timestamp();
>
> Should they be? It seems quite reasonable to me that the DBMS begins a
> transaction internally (setting transaction_timestamp()), and then a
> short while later begins executing the statement submitted by the user,
> at which point statement_timestamp() is set.
>
> Perhaps ensuring they are identical for single-statement transactions is
> the best behavior, I just don't think this is required behavior.
Yea, perhaps it isn't required, but it seems like a good idea. It will
avoid confusion and seems logical. :-)
> > And these should be the same:
> >
> > $ psql -c '
> > INSERT INTO t VALUES (statement_timestamp());
> > INSERT INTO t VALUES (statement_timestamp());' test
> > INSERT 0 1
>
> Uh, why should these be the same?
This gets into cases where a single statement generates more than one
parsenode, e.g. rules. We want all the parse nodes to have the same
timestamp.
We had a long discussion that the statement time isn't really
meaningful/logical, so I went with code that said the statement arrival
time is the proper time to return, and be consistent.
--
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. +