Re: Range Types: empty ranges

On Fri, 2011-02-11 at 13:50 -0500, Robert Haas wrote:
> On Fri, Feb 11, 2011 at 1:11 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> > Similarly, "intersection" of ranges is somewhat analogous to
> > multiplication of numbers.
>
> I had a feeling that we might be going in this direction. It strikes
> me that this case is a bit like division by zero.

Except that we do happen to allow the value zero and wait 'til someone
divides by it before throwing an error. So I think that's more of a
point toward allowing empty ranges than rejecting them.

> It's kind of a
> nuisance that dividing by zero throws an error and we COULD fix that
> by making it return NULL or NaN or some new distinguished value DbZ.

But empty ranges are actually quite well-defined, in a way similar to an
empty set.
* it can meaningfully result in a non-empty range at a later stage
of computation
* it increases the number of tautologies, rather than decreasing
them like NULL

I guess what I'm saying is that DbZ doesn't seem particularly useful to
carry along, while and empty range plausibly is.

> But then we'd have to define what happens when you feed DbZ into every
> other operation in the system, and similarly here.

If your point is that empty ranges need to be handled specially
sometimes, I agree. That is the semantic cost which I identified in the
original email. Are the benefits worth it?

> If we define two
> non-overlapping ranges as intersecting to NULL, or as throwing an
> error, then everything else is clear after that.

Well, there is a certain amount of localized clarity, I will agree with
that. The complexity comes when you accidentally rely on some
transformation which seems logically sound, but could result in a
transient empty range, which then throws an error.

Regards,
Jeff Davis