Horton

Re: Range Types - typo + NULL string constructor

Jeff Davis <pgsql@j-davis.com>

View thread
From: Jeff Davis <pgsql@j-davis.com>
To: Thom Brown <thom@linux.com>
Cc: Florian Pflug <fgp@phlo.org>, Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Erik Rijkers <er@xs4all.nl>, pgsql-hackers@postgresql.org
Date: 2011-10-10T16:44:51Z
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

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.

But then "int4range(1,8)" would still mean "int4range(1,8,'[)')" and
therefore '[1,7]'. I used to have a "default_flags" parameter that could
also be specified at type creation time that would control the default
third parameter (the parameter that controls inclusivity) of the
constructor. However, I removed the "default_flags" parameter because,
as Florian pointed out, it's better to have a consistent output from the
constructor.

I'm open to suggestions, including potentially bringing back
"default_flags".

Regards,
	Jeff Davis