Rod Taylor <pg@rbt.ca> writes:
> On Thu, 2005-06-23 at 22:27 +0200, Markus Bertheau wrote:
>> Dnia 23-06-2005, czw o godzinie 16:19 -0400, Rod Taylor napisa�(a):
>>> The data types are different, as one has the timestamp to (6) decimal
>>> places after seconds.
>>
>> That's strange. I explicitly specified ::TIMESTAMP on both the view and
>> the table. Is that not unambiguous?
> LOCALTIMESTAMP is probably more specific, so it folds the length in.
> If you SELECT 'abc'::varchar(6)::varchar, the end type is varchar(6).
Yeah, this is exactly what's happening --- if you look at gram.y,
LOCALTIMESTAMP is expanded to "'now'::text::timestamp(6)". I am
unconvinced that the (6) is a very good idea though. The code says
/* SQL99 mandates a default precision of 6 for timestamp. * Also, that is about
asprecise as we will get since * we are using a microsecond time interface. * -
thomas2001-12-07 */ d->typmod = 6;
but it doesn't seem to me to follow from what the spec says that we need
to explicitly cast the result of now() to six places. As long as it's
coming from gettimeofday it can't have more than 6 places anyway, and so
we might as well save the extra coercion step. (The parser *will* tack
on a separate coercion function call when presented with this parse
tree.)
In short, I'm inclined to remove the above-quoted lines, and similarly
for CURRENT_TIME, CURRENT_TIMESTAMP, and LOCALTIME. Thoughts?
regards, tom lane
