On Jan 9, 2008 10:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Really? I think you've confused some unimplemented decorative syntax
> with what the underlying datatype will or won't do.
Fair enough. The underlying type certainly will do it since it works
without the opt_interval.
> > This is inconsistent. I would like to ultimately not allow operations
> > on interval combinations that are not allowed by the SQL standard.
>
> The spec's approach to datetime operations in general is almost totally
> brain-dead, and so you won't find a lot of support around here for hewing
> to the straight-and-narrow-spec-compliance approach. If they have not
> even heard of daylight-savings time, how can anyone credit them with any
> meaningful contact with the real world? We'll cite the spec where it
> suits us, but in this area "the spec says you can't do that" carries
> very little weight.
DST in the sense of doing arithmetic on timestamps? I was not aware
that the standard defined the result in such a way that precluded
allowing for DST and leap seconds and whatever other time warps you
wanted to allow in your database. In fact, looking over the draft of
the 2003 standard looks like it takes DST into consideration just
fine. It just doesn't allow the use of a non-constant timezone
identifier, which admittidly would be useful.
> Or were you planning to lobby for removal of our DST support, too?
No. The DST support makes sense.
wt