Re: [SQL] [GENERAL] CURRENT_TIMESTAMP - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: [SQL] [GENERAL] CURRENT_TIMESTAMP |
Date | |
Msg-id | 200210051902.g95J2Mf09842@candle.pha.pa.us Whole thread Raw |
In response to | Re: [SQL] [GENERAL] CURRENT_TIMESTAMP (Manfred Koizar <mkoi-pg@aon.at>) |
Responses |
Re: [SQL] [GENERAL] CURRENT_TIMESTAMP
|
List | pgsql-hackers |
Yes, I agree with you Manfred, but more people _don't_ want it to change, and like it the way it is, so we will just keep it and add now("string"). Added to TODO: * Add now("transaction|statement|clock") functionality I have attached an SGML patch that explains the issues with CURRENT_TIMESTAMP in more detail. --------------------------------------------------------------------------- Manfred Koizar wrote: > 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. > > Servus > Manfred > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 Index: doc/src/sgml/func.sgml =================================================================== RCS file: /cvsroot/pgsql-server/doc/src/sgml/func.sgml,v retrieving revision 1.126 diff -c -c -r1.126 func.sgml *** doc/src/sgml/func.sgml 24 Sep 2002 20:14:58 -0000 1.126 --- doc/src/sgml/func.sgml 5 Oct 2002 19:00:15 -0000 *************** *** 4293,4304 **** </informalexample> <para> ! It is quite important to realize that ! <function>CURRENT_TIMESTAMP</function> and related functions all return ! the time as of the start of the current transaction; their values do not ! increment while a transaction is running. But ! <function>timeofday()</function> returns the actual current time. </para> <para> All the date/time data types also accept the special literal value --- 4293,4309 ---- </informalexample> <para> ! It is important to realize that ! <function>CURRENT_TIMESTAMP</function> and related functions return ! the start time of the current transaction; their values do not ! change during the transaction. <function>timeofday()</function> ! returns the wall clock time and does advance during transactions. </para> + + <note> + Many other database systems advance these values more + frequently. + </note> <para> All the date/time data types also accept the special literal value
pgsql-hackers by date: