On Mon, Oct 09, 2006 at 03:49:50PM -0400, Tom Lane wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
