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 <pg...@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 > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
