Thomas Lockhart wrote:
> ...
> > Seems that isn't helping enough to reduce the number of people who are
> > surprised by our behavior.  I don't think anyone would be surprised by
> > statement time.
> 
> I think that there is no compelling reason for changing the current 
> behavior. There is no *single* convention used by all other databases, 
> and *if* the standard specifies this as "statement time" then afaict no 
> database implements that exactly.

I was attempting to get closer to the standards and to other databases,
and to make it perhaps more intuitive.

> Transaction time is the only relatively deterministic time, and other 
> times are (or could be) available using other function calls. So what 
> problem are we trying to solve?
> 
> There is no evidence that a different convention would change the number 
> of folks who do not understand what convention was chosen.
> 
> Arguing to change the current implementation without offering to include 
> the functionality to handle all of the scenarios seems to be premature. 
> And arguing that a change would be clearer to some folks is not 
> compelling; "transaction start" is at least as easily understood as any 
> other definition we could make.

Yes, clearly, we will need to have all three time values available to
users.  With three people now suggesting we don't change, I will just
add to TODO:

	Add now("transaction|statement|clock") functionality

Is that good?

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

Thu, 3 Oct 2002 21:58:05 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [SQL] [GENERAL] CURRENT_TIMESTAMP
Bruce Momjian <pgman@candle.pha.pa.us> wrote:

> Yes, clearly, we will need to have all three time values available to
> users.  With three people now suggesting we don't change, I will just
> add to TODO:
>
> Add now("transaction|statement|clock") functionality
>
> Is that good?

CURRENT_TIMESTAMP etc. are converted to now()::TIMESTAMP, at least in 7.2,
right?
So when there are all three options available, it would be easy to change
the behaviour of CURRENT_DATE/TIME/TIMESTAMP, right?

SET .. or GUC would be options, no?

Best Regards,
Michael Paesold


Fri, 4 Oct 2002 18:14:04 +0200
"Michael Paesold" <mpaesold@gmx.at>
Re: CURRENT_TIMESTAMP
Michael Paesold wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> wrote:
> 
> > Yes, clearly, we will need to have all three time values available to
> > users.  With three people now suggesting we don't change, I will just
> > add to TODO:
> >
> > Add now("transaction|statement|clock") functionality
> >
> > Is that good?
> 
> CURRENT_TIMESTAMP etc. are converted to now()::TIMESTAMP, at least in 7.2,
> right?
> So when there are all three options available, it would be easy to change
> the behaviour of CURRENT_DATE/TIME/TIMESTAMP, right?
> 
> SET .. or GUC would be options, no?

Well, we are going to make all of them available in 7.4, but I don't see
a reason to have CURRENT_TIMESTAMP changing based on GUC.  If you want a
specific one, use now("string").

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

Fri, 4 Oct 2002 13:48:44 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: CURRENT_TIMESTAMP