On May 24, 2006, at 7:37 , Brendan Jurd wrote:
I've been searching through the archives for discussions relating to
intervals, but haven't come across the one you're describing. Most
probably because there have been a LOT of discussions relating to
intervals.
I don't have links to the thread
Brendan,
> Could you elaborate on how it sucked? Apart from the issue of
> daylight savings which Tom has mentioned, what are these limitations
> that needed to be worked around?
Well, actually, the DST thing was pretty severe -- it made timestamptz
unusable. That's why we partitioned interval
Brendan Jurd wrote:
> On 5/24/06, Josh Berkus wrote:
> > Brendan,
> >
> > > There are two classes of intervals. One class, called year-month
> > > intervals, has an express or implied datetime precision that includes
> > > no fields other than YEAR and MONTH, though not both are required. The
> >
On 5/24/06, Josh Berkus wrote:
Brendan,
> There are two classes of intervals. One class, called year-month
> intervals, has an express or implied datetime precision that includes
> no fields other than YEAR and MONTH, though not both are required. The
> other class, called day-time intervals, h
Brendan,
> There are two classes of intervals. One class, called year-month
> intervals, has an express or implied datetime precision that includes
> no fields other than YEAR and MONTH, though not both are required. The
> other class, called day-time intervals, has an express or implied
> interva
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> I've been looking at the postgres interval implementation lately, and
> I'm interested in putting together an improved implementation that
> accords more closely with the SQL specification, in particular with:
Appealing to the SQL spec isn't going to ta
I don't see how this makese our system any better than it does not. It
just seems to eliminate the 30-day problem by not allowing it. That
doesn't seem to be a step forward.
---
Brendan Jurd wrote:
> Hi all,
>
> I've been
