On Mon, 2011-06-27 at 12:25 +0200, Florian Pflug wrote:
> Does the current definition of length(range), i.e.
> upper(range) - lower(range)
> deal correctly with open vs. closed ranges and unbounded ranges? I'm thinking
> that it probably doesn't - what would be the results of
> length('[0,1]'::intrange) -- Should be 2
> length('[0,1)'::intrange) -- Should be 1
I alluded to this problem in an earlier email.
I think this would need to be handled by the "canonical" function. If
the canonical function is specified to return values in [) or (] form,
then we'd get the behavior above.
However, it's a little strange, because for discrete ranges you probably
want cardinality, not length. I don't have a clear idea on exactly what
behavior users will expect in this case, which is a pretty good argument
to leave length() out.
> length('[0,inf]'::intrange) -- Should be infinity, but ints can't
> represent that, can't they?
That would throw an exception currently, for exactly the reason you
mention.
> If it cannot be easily made to support these cases, than I vote for
> removing it all together.
I now agree. I think you've brought up some good reasons for that. If
users write upper(r)-lower(r), then they know what the semantics will
be; or they can easily write their own length() function (perhaps
specific to a range type).
Regards,Jeff Davis
