From: | "Brendan Jurd" <direvus(at)gmail(dot)com> |
---|---|
To: | josh(at)agliodbs(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SQL compliant interval implementation |
Date: | 2006-05-23 22:37:18 |
Message-ID: | 37ed240d0605231537r4eb6018dm374744f2043557e1@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 5/24/06, Josh Berkus <josh(at)agliodbs(dot)com> 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, has an express or implied
> > interval precision that can include any fields other than YEAR or
> > MONTH.
>
> Yeah, we used to do that. It sucked. In fact, most developers of
> applications which were calendar-heavy ended up using custom data types to
> work around the SQL-spec INTERVAL limitations. And that benefits nobody.
>
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?
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.
Regards,
BJ
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-05-23 22:43:48 | Re: SQL compliant interval implementation |
Previous Message | Josh Berkus | 2006-05-23 22:16:31 | Re: SQL compliant interval implementation |