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@j-davis.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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>
