Re: [SQL] [GENERAL] CURRENT_TIMESTAMP

Поиск
Список
Период
Сортировка
От Manfred Koizar
Тема Re: [SQL] [GENERAL] CURRENT_TIMESTAMP
Дата
Msg-id mlctpu8td1g1m4npddjgpublc7k43leo3i@4ax.com
обсуждение исходный текст
Ответ на Re: [SQL] [GENERAL] CURRENT_TIMESTAMP  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: [SQL] [GENERAL] CURRENT_TIMESTAMP
Re: [SQL] [GENERAL] CURRENT_TIMESTAMP
Список 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 по дате отправления:

Предыдущее
От: Gavin Sherry
Дата:
Сообщение: Branch prediction
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Proposed LogWriter Scheme, WAS: Potential Large Performance