On Sep21, 2011, at 09:23 , Jeff Davis wrote:
> On Mon, 2011-09-19 at 18:32 +0200, Florian Pflug wrote:
>> 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?
>
> I think that the range input should *parse* NULL in a similar way, but
> reject it. So, to make it the range between two definite strings, you'd
> do:
>
> '[A,"NULL")'::textrange
>
> which would be equal to textrange('A','NULL','[)'). Without the quotes,
> it would detect the NULL, and give an error. Open to suggestion here,
> though.
Hm, that seems like a reasonable compromise. As long as range types and
arrays agree on the same basic lexical rules regarding quoting and whitespace
(i.e. that spaces outside of double-quotes are non-significant, that keywords
like NULL and INF/Infinity are case-insensitive, ...) I'm happy I guess.
>> 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)'?
>
> I'm open to that, if you think it's an improvement I'll do it (but we
> should probably pick one identifiable string and stick with it). What
> I'd like to avoid is adding to the NULL/infinity confusion.
I've thought about this some more, and came to realize that the question
here really is whether
floatrange(0, 'Infinity'::float, '[)')
and
floatrange(0, NULL, '[)')
are the same thing or not. If they're not, then obviously using "Infinity"
to represent omitted bounds is going to be very confusing. If they are,
then using "Infinity" seems preferable. Maybe boundaries should be restricted
to numeric float values (i.e. +/-Infinity and NaN should be rejected), though
I dunno if the range type infrastructure supports that. Thoughts?
best regards,
Florian Pflug
