On 10/30/09, Sam Mason <sam@samason.me.uk> wrote:
> On Fri, Oct 30, 2009 at 01:45:24PM +0200, Marko Kreen wrote:
> > On 10/30/09, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> > > That was the point of my '1 day -25 hours' example. Whether you
> > > consider that positive or negative seems mighty arbitrary.
> >
> > If I can add it to a timestamp and get a deterministic result,
> > then we already have decided how to interpret the arbitrariness.
>
>
> The point is that it's only in relation to a specific timestamp do the
> components of an interval actually receive comparable values. For
> example, a day can be a varying number of hours, a month a varying
> number of days and a year can also vary in its number of days. Once
> you add this to a date then these components get fixed, but without any
> specific timestamp to work with these components remain undefined.
>
> I'd argue that it doesn't help to know that we can add it to a timestamp
> and get out a deterministic result. It's the fact that we have a
> deterministic comparison operator that helps us.
Slightly makes sense, but only slightly. We deterministically know,
that we dont have certain timestamp, thus we need to use some default
values. We already have situation that does that:
extract(epoch from interval)
Yes, some cases the value returned is not the same value that would
be added to a specific timestamp, but so what? How is current situation
better that we force users to manually create potentially buggy
equivalent functionality?
--
marko