On Mon, Sep 19, 2011 at 11:23 AM, Florian Pflug <f...@phlo.org> wrote: > 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.
Well, I'm not violently opposed to accepting NULL to mean an unbounded range. The semantics of "no bound at all" and "an unknown bound" (i.e. NULL) are pretty close, as Kevin also points out downthread. But I think the way Jeff actually did it is OK, too. What I really care about is that we don't talk ourselves into needing a zillion constructor functions. Making things work with a single constructor function seems to me to simplify life quite a bit, and allowing there seems essential for that. (I am also vaguely wondering what happens if if you have a text range.... is (nubile, null) ambiguous?) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
