Tom Lane writes:
> 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.
But it's only talking about statements. You can't reuse things that you
calculated for previous statements unless it says so. (Of course
implementation-dependent means that you can do anything you want to, but
let's not go there. :-)
> Actually calling time(2) at each use
> of now(), which is what the original poster seemed to want, is
> clearly *not* an allowed behavior.
What this covers is doing things like
SELECT CURRENT_TIMESTAMP as "Today", CURRENT_TIMESTAMP + 1 DAY AS "Tomorrow";
But keep in mind that other/correct SQL implementations don't have
autocommit, so if you're in some interactive SQL shell and you keep
entering
select current_timestamp;
then it won't ever advance unless you do commits in between. This doesn't
make much sense to me, as CURRENT_TIMESTAMP is defined to return the
"current time" . The point of a transaction is all data or no data, not
all the same data.
> 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.
Good point. There are probably special rules for SQL functions.
I'm not saying that this thing is a priority to me, but it's something to
consider.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
