> > > This seems fair. Would this approach imply that CURRENT_TIME and
> > > CURRENT_TIMESTAMP should not apply default precision to their return
> > > values? Right now, "CURRENT_TIME" is equivalent to "CURRENT_TIME(0)"
> > > and "CURRENT_TIMESTAMP" eq to "CURRENT_TIMESTAMP(6)".
> > Yes, I had been thinking that myself, but hadn't got round to mentioning
> > it to the list yet. (Even if you do accept default precisions for time
> > & timestamp columns, I can see nothing in the spec that justifies
> > applying those default precisions to CURRENT_TIME/TIMESTAMP. AFAICS,
> > the precision of their results when they are given no argument is
> > just plain not specified.)
>
> I'll shift the default precisions of CURRENT_TIME to match that of
> CURRENT_TIMESTAMP, which is currently six (6). As you might know, 7.2
> has sub-second system time available, which was not true in previous
> releases. But that time is only good to microseconds, so the six digits
> of precision is a good match for that.
Is this all resolved?
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026