From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Range Types: empty ranges |
Date: | 2011-02-11 20:03:20 |
Message-ID: | 1297454600.459.7.camel@jdavis-ux.asterdata.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2011-02-11 20:03:58 | Re: Debian readline/libedit breakage |
Previous Message | Stephen Frost | 2011-02-11 20:01:31 | Re: multiset patch review |