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 17:38:55 |
Message-ID: | 20061009173854.GD72517@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 09, 2006 at 12:02:12PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jim(at)nasby(dot)net> writes:
> > Sinte we already have width_bucket, I'd argue this should go in core. If
> > someone's feeling adventurous, there should probably be a double
> > precision version as well. Hrm... and maybe text...
>
> It's not clear to me why we have width_bucket operating on numeric and
> not float8 --- that seems like an oversight, if not outright
> misunderstanding of the type hierarchy. But if we had the float8
> version, I think Jeremy's problem would be solved just by applying
> the float8 version to "extract(epoch from timestamp)". I don't really
> see the use-case for putting N versions of the function in there.
Well, it would be nice to have a timestamp version so that users didn't
have to keep typing "extract(epoch from timestamp)"... but yeah, I
suspect that would work fine for timestamps. For intervals I suspect you
could just convert to seconds (if we're going to add timestamps, it
seems like we should add intervals as well).
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-10-09 17:49:37 | Re: width_bucket function for timestamps |
Previous Message | Mark Wong | 2006-10-09 17:37:32 | Re: continuing daily testing of dbt2 against postgresql |