Tom Lane <[EMAIL PROTECTED]> writes:
> That's defensible when the user issued the BEGIN himself. When the
> BEGIN is coming from some interface library's autocommit logic, it's
> a lot less defensible. If you consult the archives, you will find
> actual user complaints about "why is now() returning a very old time?"
> that we traced to use of interface layers that handle "commit()" by
> issuing "COMMIT; BEGIN;".
Hmmm... I agree this behavior isn't ideal, although I can see the case
for viewing this as a mistake by the application developer: they are
assuming that they know exactly when transactions begin, which is not
a feature provided by their language interface. They should be using
current_timestamp, and/or changing their language interface's
configuration.
That said, I think this is a minor irritation at best. The dual
drawbacks of breaking backward compatibility and making the BEGIN
semantics more confusing is enough to leave me satisfies with the
status quo.
If we do change this, I think Dennis' idea of making now() always
return the same value within a given transaction is interesting: that
might be a way to fix this problem without confusing the semantics of
BEGIN.
-Neil
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
