Re: Range Types - typo + NULL string constructor - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Range Types - typo + NULL string constructor
Date
Msg-id 1316411494.7281.161.camel@jdavis
Whole thread Raw
In response to Re: Range Types - typo + NULL string constructor  ("Erik Rijkers" <er@xs4all.nl>)
Responses Re: Range Types - typo + NULL string constructor
Re: Range Types - typo + NULL string constructor
List pgsql-hackers
On Sun, 2011-09-18 at 18:08 +0200, Erik Rijkers wrote:
> Below are 2 changes.  The first change is an elog saying 'lower' instead of 'upper'.

Done, thank you. New patch attached.

Changes:
 * documentation fixes
 * added document for pg_range catalog
 * cleaned up errors, increased error checking
 * improved pg_dump

TODO:
 * Support casts and typmod.
   - This requires adding a RangeCoerceExpr, or possibly
     overloading ArrayCoerceExpr somehow. This is likely to
     require a lot of boilerplate code and a fairly large diff.
 * Cache lookups better to avoid unnecessary SearchSysCache calls.
 * I need to find a clean way to get the operator class name in pg_dump.

> Rangetypes as it stands uses NULL to indicate INF or -INF:
>
> select int4range(2, NULL);
>
>  int4range
> ------------
>  [ 2, INF )
> (1 row)
>
>
> but refuses to accept it in the string-form:
>
> 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).

In the string form, it doesn't add any convenience to accept NULL; but
as you point out, it seems inconsistent without it.

Thoughts?

Regards,
    Jeff Davis

Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: pg_upgrade automatic testing
Next
From: Benjamin LaHaise
Date:
Subject: Re: Improve lseek scalability v3