Re: Range Types - typo + NULL string constructor
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Thom Brown <thom@linux.com>, Florian Pflug <fgp@phlo.org>, Robert Haas <robertmhaas@gmail.com>, Erik Rijkers <er@xs4all.nl>, pgsql-hackers@postgresql.org
Date: 2011-10-10T16:53:54Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Replace the "New Linear" GiST split algorithm for boxes and points with a
- 7f3bd86843e5 9.2.0 cited
Jeff Davis <pgsql@j-davis.com> writes: > On Mon, 2011-10-10 at 14:27 +0100, Thom Brown wrote: >> I don't know if this has already been discussed, but can you explain >> the following: >> >> postgres=# select '[1,8]'::int4range; >> int4range >> ----------- >> [1,9) >> (1 row) >> >> It seems unintuitive to represent a discrete range using an exclusive >> upper bound. While I agree that the value itself is correct, it's >> representation looks odd. Is it necessary? > The "canonicalize" function (specified at type creation time) allows you > to specify the canonical output representation. So, I can change the > canonical form for discrete ranges to use '[]' notation if we think > that's more expected. What if I write '[1,INT_MAX]'::int4range? The open-parenthesis form will fail with an integer overflow. I suppose you could canonicalize it to an unbounded range, but that seems unnecessarily surprising. regards, tom lane