From: | Sam Mason <sam(at)samason(dot)me(dot)uk> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Absolute value of intervals |
Date: | 2009-10-30 14:19:49 |
Message-ID: | 20091030141949.GZ5407@samason.me.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Oct 30, 2009 at 02:14:31PM +0200, Marko Kreen wrote:
> 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)
You're arguing the same point as me. Your extract code and my
comparison operator use exactly the same values as defaults when
normalizing their respective intervals. Neither of them have anything
to do with timestamps.
> 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?
Tom was arguing that it's fundamentally inappropriate to ask for the
absolute value of an interval. I was saying that we've already chosen
arbitrary values for the components of an interval for comparison and
you've just pointed out that we use the same values elsewhere. Once
we've chosen them I don't see why we shouldn't extend them to all the
places that they seem to fit, such as this absolute value operator.
I think the attached trivial bit code should do the right thing, however
I don't know what else is needed to hook everything up.
--
Sam http://samason.me.uk/
Attachment | Content-Type | Size |
---|---|---|
interval_abs.patch | text/x-diff | 639 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Vick Khera | 2009-10-30 14:24:01 | Re: checkpoints/bgwriter tuning verification |
Previous Message | Guillaume Lelarge | 2009-10-30 13:03:11 | Re: checkpoints/bgwriter tuning verification |