Re: Changing behavior of BEGIN...sleep...do something...COMMIT

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Doug McNaught <doug(at)mcnaught(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Changing behavior of BEGIN...sleep...do something...COMMIT
Date: 2003-03-30 02:22:09
Message-ID: 200303300222.h2U2M9w29262@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Doug McNaught wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> > Accordingly, it's a bad idea to invent now('clock') and make it the
> > same function as the other flavors. We could get away with making
> > now('transaction') and now('statement') ---- but the argument for this
> > was consistency, and that argument pretty much falls flat if those two
> > are one function while clock time is something else.
> >
> > So I'm back in the camp of thinking three separate parameterless
> > functions are the way to do it. We already know what now() does,
> > and we're not going to change it --- anyone want to propose names
> > for the other two?
>
> Maybe clock_time() and statement_time(), with transaction_time() an
> alias for now() (if that's seemed necessary)?

Agreed on the need to not use args for now().

We already have CURRENT_TIMESTAMP. Would CLOCK_TIMESTAMP,
TRANSACTION_TIMESTAMP, and STATEMENT_TIMESTAMP make sense, with
CURRENT_TIMESTAMP being the same as TRANSACTION_TIMESTAMP?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-03-30 02:38:22 Re: Changing behavior of BEGIN...sleep...do something...COMMIT
Previous Message Steve 2003-03-30 01:09:00 SQL Query to get Column constraints