Re: Range Types - typo + NULL string constructor
От | Jeff Davis |
---|---|
Тема | Re: Range Types - typo + NULL string constructor |
Дата | |
Msg-id | 1316411494.7281.161.camel@jdavis обсуждение исходный текст |
Ответ на | Re: Range Types - typo + NULL string constructor ("Erik Rijkers" <er@xs4all.nl>) |
Ответы |
Re: Range Types - typo + NULL string constructor
Re: Range Types - typo + NULL string constructor |
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: