On Sep19, 2011, at 17:46 , Jeff Davis wrote: > On Mon, 2011-09-19 at 17:23 +0200, Florian Pflug wrote: >> The one reason I can see in favour of supporting N-U-L-L there is >> compatibility with arrays. > > But arrays actually do store and produce NULLs; ranges don't.
Hm, yeah, granted. But OTOH, clients will very likely use NULL, null, nil or something similar as a bound to represent unbounded ranges. And those will probably already be mapped to SQL's NULL. So in practice, people will think of unbounded ranges having the (lower or upper) bound NULL I think. >> 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. > > I'm not clear on how accepting "NULL" would really save effort. With > ranges, the brackets have an actual meaning (inclusivity), and empty > ranges have no brackets at all. So I don't think it's going to be easy > to write one function to parse everything. No, but more similar the format are the easier it gets to at least factor the hairy parts of such a parser into a common subroutine. Assume that we don't support NULL as an alias for INF. What would then be the result of '[A,NULL)'::textrange? Presumably, it'd be the same as textrange('A','NULL','[)'). Which think is a bit surprising, since '[A,NULL]'::text produces ARRAY['A',NULL], *NOT* ARRAY['A','NULL']. BTW, we currently represent infinity for floating point values as 'Infinity', not 'INF'. Shouldn't we do the same for ranges, i.e. make int4range(0,NULL,'[)')::text return '[0,Infinity)'? 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