Brent Verner <brent@rcfile.org> writes:
> [2001-12-04 18:15] Tom Lane said:
> | But you are definitely right that
> |
> | time '17:12:28.123'
> sql-99 seems to contradict this assertion.
> page 160 (Syntax Rules, 6.1 <data type>)
> 30) If <time precision> is not specified, then 0 (zero) is implicit.
> If <timestamp precision> is not specified, then 6 is implicit.
But that's <data type>, ie, they're specifying the implied width of
a table column that's declared "foo time". The rules for <time literal>
are different.
Our problem is that we want to generalize the notion of <time literal>
to be <datatype> <string literal>, and this makes it hard to have
datatype-specific rules that differ from the rules that apply in the
column-datatype context.
My thought is that we should resolve this conflict by rejecting the
part of the spec that assigns fixed default precisions to time
and timestamp columns, the same as we have done for type numeric.
There's no benefit to the user in that requirement; it's only a
crutch for implementations that cannot cope with variable-width
columns effectively. If people want a column that rounds fractional
inputs to integral seconds, let 'em say "TIME(0)". But I don't
think that "TIME" should do so, especially when the spec provides
no alternative way to get the effect of "time with no particular
precision restriction". It's the old "text vs varchar(N)" game all
over again.
> I believe the proper solution would be to update the documentation
> to reflect the fact that "TIME 'hh:mm:ss.ff'" will correctly drop
> the '.ff' seconds fraction.
No, because that behavior is *not* correct, neither per spec nor per
our historical behavior.
regards, tom lane
