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

From Bruce Momjian
Subject Re: [SQL] [GENERAL] CURRENT_TIMESTAMP
Date
Msg-id 200210032018.g93KI8110524@candle.pha.pa.us
Whole thread Raw
Responses Re: [SQL] [GENERAL] CURRENT_TIMESTAMP  (Andrew Sullivan <andrew@libertyrms.info>)
List pgsql-hackers
[ Thread moved to hackers.]

OK, I have enough information from the various other databases to make a
proposal.  It seems the other databases, particularly Oracle, record
CURRENT_TIMESTAMP as the time of statement start.  However, it isn't the
time of statement start from the user's perspective, but rather from the
database's perspective, i.e. if you call a function that has two
statements in it, each statement could have a different
CURRENT_TIMESTAMP.

I don't think that is standards-compliant, and I don't think any of our
users want that.  What they probably want is to have a fixed
CURRENT_TIMESTAMP from the time the query is submitted until it is
completed.  We can call that the "statement arrival time" version of
CURRENT_TIMESTAMP.  I don't know if any of the other databases support
this concept, but it seems the most useful, and is closer to the
standards and to other databases than we are now.

So, we have a couple of decisions to make:
Should CURRENT_TIMESTAMP be changed to "statement arrival time"?Should now() be changed the same way?If not, should
now()and CURRENT_TIMESTAMP return the same type ofvalue?
 

One idea is to change CURRENT_TIMESTAMP to "statement arrival time", and
leave now() as transaction start time. 

Also, should we added now("val") where val can be "transaction",
"statement", or "clock"?

--  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,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: DROP COLUMN misbehaviour with multiple inheritance
Next
From: Hannu Krosing
Date:
Subject: Re: DROP COLUMN misbehaviour with multiple inheritance