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