Re: [SQL] [GENERAL] CURRENT_TIMESTAMP - Mailing list pgsql-hackers

From Manfred Koizar
Subject Re: [SQL] [GENERAL] CURRENT_TIMESTAMP
Date
Msg-id mlctpu8td1g1m4npddjgpublc7k43leo3i@4ax.com
Whole thread Raw
In response to Re: [SQL] [GENERAL] CURRENT_TIMESTAMP  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [SQL] [GENERAL] CURRENT_TIMESTAMP  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [SQL] [GENERAL] CURRENT_TIMESTAMP  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
On Sat, 5 Oct 2002 00:29:03 -0400 (EDT), Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
>
>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
functions-datetime.html?


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

On Fri, 04 Oct 2002 09:54:42 -0400, Tom Lane <tgl@sss.pgh.pa.us>
wrote:
>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.

ServusManfred


pgsql-hackers by date:

Previous
From: Gavin Sherry
Date:
Subject: Branch prediction
Next
From: Bruce Momjian
Date:
Subject: Re: Proposed LogWriter Scheme, WAS: Potential Large Performance