Re: time stops within transaction

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(at)gmx(dot)net http://yi.org/peter-e/