On Fri, 2011-02-11 at 10:28 -0800, Josh Berkus wrote:
> I guess I'm having trouble tying the concept of empty ranges to any
> reality external to the database.
That's true, but in the same sense as zero has no meaning outside of the
database.
It's really that it has nice mathematical properties coming from set
theory. Take the distributive law:
A UNION (B INTERSECT C) = (A UNION B) INTERSECT (A UNION C)
If (B INTERSECT C) is empty, then the result should be A. With empty
ranges, that holds on both sides. Without them, it doesn't hold on the
left side.
People implicitly use this kind of logic all the time when constructing
queries. If one form works, and the other throws an error, it will cause
confusion.
> For example, what would the time range:
>
> '('15:15:00','15:15:00')'
>
> ... represent exactly? "A non-existant point in time which might or
> might not be near 3:15 PM"?
That's meaningless and will throw an error. An empty range is not
anchored at any particular point, so any two empty ranges are equal.
> BUT ... if I, in one of my applications, accidentally defined something
> as having the range '('15:15:00','15:15:00')', I would *want* the
> database to through an error and not accept it.
Absolutely. That kind of input should throw an error (and does).
> So, if we allow empty ranges of this kind, I would want a GUC for
> "allow_empty_ranges".
I think that would be the least desirable option. If we don't like empty
ranges, let's prohibit them entirely.
Or, there are always check constraints...
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
