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