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 →
  1. Replace the "New Linear" GiST split algorithm for boxes and points with a

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