Re: text -> time cast problem

> > > 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026