On Fri, 2011-02-11 at 14:19 -0600, Kevin Grittner wrote: > Well, in the receipt number example there are multiple ranges in use > for each year, and ranges for multiple years. If we get to the idea > of a multi-ranges, this would be very handy for certain types of > reports -- especially for auditors. It's not that we can't do with > with discrete begin and end columns -- we do that now; but it seemed > a potentially beneficial use of ranges for us, if they can represent > the needed states. People already talk about these as ranges, just > in terms of the common English understanding of the word.
I think that might indicate that the word "range" is a little too loose. The definition that I've been using is more like a mathematical interval. > Perhaps it was a mistake to get so concrete rather than conceptual > -- basically, it seems like it could be a useful concept for any > planned or scheduled range with an indeterminate end point, which > you want to "reserve" up front and record in progress until > complete. Maybe this is a range... would it be served by: (5, INF) or: [5, INF) ? That's already supported, and it means "all points greater than 5". > Of course, the *most* useful places for our shop to have ranges are > temporal. Many (most?) of those are situations where you start with > a range with an unknown end and later (often years later) fill in > the end of the range based on some event which finally closes it. > Again, two discreet dates with a null-capable end-date work, but I > can see where ranges could potentially be more powerful. Ranges support infinite boundaries, but do not support NULL (previous discussion concluded that NULL boundaries were likely to be confusing and served no obvious use case not handled by infinity). 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