Re: Range Types: << >> -|- ops vs empty range - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Range Types: << >> -|- ops vs empty range
Date
Msg-id 1299865026.3474.58.camel@jdavis
Whole thread Raw
In response to Re: Range Types: << >> -|- ops vs empty range  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Range Types: << >> -|- ops vs empty range
List 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



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Non-simultaneous file system snapshots as backups
Next
From: Tom Lane
Date:
Subject: Re: B-tree parent pointer and checkpoints