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