From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Erik Rijkers <er(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Range Types - typo + NULL string constructor |
Date: | 2011-09-19 13:33:29 |
Message-ID: | CA+TgmobkWFBw6S7AC1h3YW4zugm4zBYu5bE9jgORq77TNrgj7g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Sep 19, 2011 at 1:51 AM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>> select '[ 2 , NULL )'::int4range;
>> ERROR: NULL range boundaries are not supported
>> LINE 1: select '[ 2 , NULL )'::int4range;
>
> I think this might require more opinions. There is a trade-off here
> between convenience and confusion: accepting NULL is convenient in the
> constructors, because it avoids the need to have extra constructors just
> for unbounded ranges; but could lead to confusion between NULL and INF
> (which are not the same).
I agree with this line of reasoning. I think we will be making pain
for ourselves if we need to invent a bunch more constructors just to
have a way of indicating an unbounded range, but OTOH I don't see any
compelling reason why the type input function needs to accept N-U-L-L.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Thom Brown | 2011-09-19 13:41:06 | Re: CUDA Sorting |
Previous Message | Robert Haas | 2011-09-19 13:30:22 | Re: Improve lseek scalability v3 |