From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Erik Rijkers <er(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Range Types: << >> -|- ops vs empty range |
Date: | 2011-03-11 17:37:06 |
Message-ID: | 1299865026.3474.58.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2011-03-11 at 08:37 -0500, Bruce Momjian wrote:
> Where are we on this?
The options are:
1. Rip out empty ranges. Several people have been skeptical of their
usefulness, but I don't recall anyone directly saying that they should
be removed. Robert Haas made the point that range types aren't closed
under UNION:
http://archives.postgresql.org/pgsql-hackers/2011-02/msg01045.php
So the additional nice mathematical properties provided by empty ranges
are not as important (because it wouldn't be perfect anyway).
2. Change the semantics. Erik Rijkers suggested that we define all
operators for empty ranges, perhaps using NULL semantics:
http://archives.postgresql.org/pgsql-hackers/2011-02/msg00942.php
And Kevin Grittner suggested that there could be discrete ranges of zero
length yet a defined starting point:
http://archives.postgresql.org/pgsql-hackers/2011-02/msg01042.php
3. Leave empty ranges with the existing "empty set" semantics. Nathan
Boley made a good point here:
http://archives.postgresql.org/pgsql-hackers/2011-02/msg01108.php
Right now it's #3, and I lean pretty strongly toward keeping it. Without
#3, people will get confused when fairly simple operations fail in a
data-dependent way (at runtime). With #3, people will run into problems
only in situations where it is fairly dubious to have an empty range
anyway (and therefore likely a real error), such as finding ranges "left
of" an empty range.
Otherwise, I'd prefer #1 to #2. I think #2 is a bad path to take, and
we'll end up with a lot of unintuitive and error-prone operators.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-03-11 17:41:09 | Re: B-tree parent pointer and checkpoints |
Previous Message | Bruce Momjian | 2011-03-11 17:36:28 | Re: Non-simultaneous file system snapshots as backups |