On Sep19, 2011, at 15:33 , Robert Haas wrote: > On Mon, Sep 19, 2011 at 1:51 AM, Jeff Davis <pg...@j-davis.com> wrote: >>> 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). > > I agree with this line of reasoning. I think we will be making pain > for ourselves if we need to invent a bunch more constructors just to > have a way of indicating an unbounded range, but OTOH I don't see any > compelling reason why the type input function needs to accept N-U-L-L.
The one reason I can see in favour of supporting N-U-L-L there is compatibility with arrays. I've recently had the questionable pleasure of writing PHP functions to parse and emit our textual representations of arrays, records, dates and timestamps. After that experience, I feel that the number of similar-yet-slightly-different textual input output format for non-primitive types is already excessive, and any further additions should be modeled after some existing ones. (And BTW, why in heavens sake, is date and time input and output asymmetric for some DateStyle settings? Asymmetric like in you need to send one format, but get back another...) best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers