On Mon, Oct 09, 2006 at 03:49:50PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jim@nasby.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@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)