On Fri, 2011-02-11 at 13:50 -0500, Robert Haas wrote:
> On Fri, Feb 11, 2011 at 1:11 PM, Jeff Davis <pg...@j-davis.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
