| From: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> |
|---|---|
| To: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> |
| Cc: | Alban Hertroys <haramrae(at)gmail(dot)com>, Chris Bartlett <c(dot)bartlett(at)paradise(dot)net(dot)nz>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Can't figure out how to use now() in default for tsrange column (PG 9.2) |
| Date: | 2012-07-16 15:57:02 |
| Message-ID: | CA+mi_8b7FdqkLBKRS0QmSQOjak-BjsMx-uqT_yRTA4_qQ0mYRw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, Jul 16, 2012 at 3:56 PM, Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> wrote:
> On 07/16/2012 07:41 PM, Alban Hertroys wrote:
>>>>
>>>> BTW, that second value looks a whole lot like a poorly thought out
> Yup. The 'infinity' value doesn't play well with all database access APIs
> and languages, though.
It doesn't even play well with PostgreSQL's extract(). I reported it
some times ago but as of 9.1.4 it has not been fixed.
=# select extract(epoch from 'infinity'::timestamp);
date_part
-----------
0
This makes 'infinity' a problematic choice in any application
requiring a mapping between dates and reals, such as when using
intervals in gist indexes.
-- Daniele
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Nolan | 2012-07-16 15:58:57 | Re: Replication/cloning: rsync vs modification dates? |
| Previous Message | Chris Angelico | 2012-07-16 15:45:16 | Re: Replication/cloning: rsync vs modification dates? |