From: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeremy Drake <pgsql(at)jdrake(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: width_bucket function for timestamps |
Date: | 2006-10-09 21:51:59 |
Message-ID: | 20061009215159.GS72517@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 09, 2006 at 03:49:50PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jim(at)nasby(dot)net> writes:
> > On Mon, Oct 09, 2006 at 01:49:37PM -0400, Tom Lane wrote:
> >> This is exactly the slippery slope I don't care to start down.
>
> > I guess I'm confused as to how this is any different from other
> > functions where we've provided multiple input arguments, such as the
> > aggregate functions.
>
> The salient reason is that the spec only defines width_bucket for numeric
> input arguments, whereas stuff like max/min is defined *by the spec* for
> other data types.
>
> Since there's no spec-based argument for allowing width_bucket for other
> datatypes, and only an (IMHO) very weak use-case for it, I don't think
> we should add the clutter.
Catalog or code clutter? ISTM that it wouldn't take much extra work at
all to provide this for timestamps or intervals...
In any case, having a faster version that used double certainly seems
like it'd be useful. It'd probably allow the OP to go back to his
original, simple version.
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2006-10-09 21:54:59 | Re: [HACKERS] timestamp subtraction (was Re: formatting intervals with to_char) |
Previous Message | Jeremy Drake | 2006-10-09 21:11:59 | Re: width_bucket function for timestamps |