Re: text -> time cast problem

[2001-12-06 13:00] Tom Lane said:
| 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.

Understood now.

I'd  misunderstood the meaning of "if specified" in the <time literal>
definition;  specifically, I interpreted it as "if specified by 
<time precision>" as opposed to the intended meaning of "if specified 
in <time string>"... so off I went seeking additional definitions
to support treating "TIME <time string>" as "TIME(0) <time string>"...

Thanks for swinging the clue stick my way :-)

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

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)".

cheers. brent

-- 
"Develop your talent, man, and leave the world something. Records are 
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing."  -- Duane Allman