On Sep19, 2011, at 15:33 , Robert Haas wrote:
> On Mon, Sep 19, 2011 at 1:51 AM, Jeff Davis <pgsql@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
