Re: Range Types: empty ranges - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Range Types: empty ranges
Date
Msg-id 4D552F7A020000250003A873@gw.wicourts.gov
Whole thread Raw
In response to Range Types: empty ranges  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
Jeff Davis <pgsql@j-davis.com> wrote:
> The philosophy is that they are essentially the "zero" value of
> any range type. Like the number zero, it allows closure over
> operations that would otherwise return an error.
Well, zero has a pretty well defined and easy to understand meaning.
How many ostriches do you have in your back yard?  In my case,
zero.  That's distinct from NULL, which would mean the answer is
unknown.
> Similarly, "intersection" of ranges is somewhat analogous to
> multiplication of numbers.
Ah, so the point is that the intersection of '[13:00,15:00)' and
'[08:00,10:00)' is the empty range, not NULL -- because you *know*
they don't overlap?
That seems useful.
What seems not useful is to say that such a value is both strictly
to the right *and* strictly to the left of a range.  That seems to
fly in the face of the normal meaning of "strict".  Nor does it seem
reasonable to say that it is adjacent to a range.  It seems like it
would be useful to be able to say that if A is adjacent to B and B
is adjacent to C that the three ranges could be considered as one
contiguous range.  You'd get in trouble with such an assumption if
an empty B was considered adjacent to all ranges.  I see similar
problems with an empty B if A is strictly to the left of B and B is
strictly to the left of C, where C is strictly to the left of A.
I'm somewhat inclined to agree with Robert that such comparisons
should not throw errors.  At this point, my inclination is to say
that UNKNOWN should be the result (which I believe is equivalent to
NULL::boolean).
-Kevin


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Debian readline/libedit breakage
Next
From: Kääriäinen Anssi
Date:
Subject: Re: ALTER EXTENSION UPGRADE, v3