Re: Range Types - typo + NULL string constructor

hello

sorry for late assign to discussion.

I don't think so using NULL instead INF is a good idea.

Regards

Pavel Stehule

2011/9/19 Jeff Davis <pgsql(at)j-davis(dot)com>:
> 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
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>