Re: Can't figure out how to use now() in default for tsrange column (PG 9.2)

From: David Johnston <polobo(at)yahoo(dot)com>
To: Rafal Pietrak <rafal(at)zorro(dot)isa-geek(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <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-17 13:30:55
Message-ID: E1ECFD3E-DDE8-48BE-8682-AB5BCAB25D4C@yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Jul 17, 2012, at 2:32, Rafal Pietrak <rafal(at)zorro(dot)isa-geek(dot)com> wrote:

> On Mon, 2012-07-16 at 14:08 -0400, David Johnston wrote:
> [------------]
>>
>> Specific, but unknown (e.g., day of week, month, year, etc...) results could
>> return "NaN" though "NULL" is also, probably more, reasonable given the
>> context.
>>
>> The goal would be to use "Infinity" in case where "<>" comparisons are
>> common and use "NULL" where "=" comparisons are common.
>
> Is that even possible to implement? (e.g.: "SELECT * FROM log WHERE
> start_date <> 'XXXX-YY-ZZ' and end_date = 'ZZZZ-AA-BB'" - when both
> start_date and end_date possibly have 'infinity')

I was unclear. I intended "<>" to mean "greater than and less than comparisons" as opposed to not equals comparisons. Equality and inequality are two sides to the same coin.

>
> Anyway, "NaN" looks quite appealing, particulary since currently:
>
> SELECT date_part('year','infinity'::timestamp ) ;
> date_part
> -----------
> 0
> (1 row)
>
> ... can lead to applications misbehaving in strange ways.
>
> I feal that date_part() on infinity, should behave "similarly to"
> division by zero - an exception. But seeing a lot of code obfuscated
> with checks for division by zero before doing an opperation, I'd opt for
> silently returning a NaN in most cases, with fields like 'year',
> 'century', 'epoch', etc. returning 'Infinity'.
>
> -R
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Olga Vingurt 2012-07-17 13:37:15 Re: DB fails to start: "Could not read from file "pg_clog/0003" at offset 212992: No error.
Previous Message KOTa 2012-07-17 10:29:01 Re: installation problem with postgres password