On Sat, 5 Oct 2002 00:29:03 -0400 (EDT), Bruce Momjian
>OK, are we agreed to leave CURRENT_TIMESTAMP/now() alone and just add
>now("string")?  If no one replies, I will assume that is a yes and I
>will add it to TODO.

So my view of CURRENT_TIMESTAMP not being spec compliant didn't find
much agreement.  No problem, such is life.

May I suggest that a "Compatibility" section is added to the bottom of

In case this issue is revisited later let me add for the archives:

On Fri, 04 Oct 2002 09:54:42 -0400, Tom Lane <[EMAIL PROTECTED]>
>Freezing CURRENT_TIMESTAMP goes right along with that, and in fact makes
>a lot of sense, because it tells you exactly what time your snapshot
>of the database state was taken.

I like this interpretation.  But bear in mind that a transaction's own
actions are visible to later commands in the same transaction.
Looking at the clock is an "own action", so this is perfectly
compatible with (my reading of) General Rule 1.

A statement does not see its own modifications which corresponds to
(my interpretation of) General Rule 3.

And one last thought:  There are applications out there that are not
written for one specific database backend.  Having to replace
CURRENT_TIMESTAMP by PG-specific now('statement') is just one more
pain in trying to be portable across different backends.


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to