Re: Range Types - typo + NULL string constructor

Jeff Davis <pgsql@j-davis.com>

From: Jeff Davis <pgsql@j-davis.com>
To: Erik Rijkers <er@xs4all.nl>
Cc: pgsql-hackers@postgresql.org
Date: 2011-09-19T05:51:34Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Replace the "New Linear" GiST split algorithm for boxes and points with a

Attachments

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