Horton

Re: Range Types - typo + NULL string constructor

Thom Brown <thom@linux.com>

View thread
From: Thom Brown <thom@linux.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Florian Pflug <fgp@phlo.org>, Robert Haas <robertmhaas@gmail.com>, Erik Rijkers <er@xs4all.nl>, pgsql-hackers@postgresql.org
Date: 2011-10-10T17:53:34Z
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 10 October 2011 18:45, Jeff Davis <pgsql@j-davis.com> wrote:
> On Mon, 2011-10-10 at 18:39 +0100, Thom Brown wrote:
>>  So the default boundaries should be '[]' as opposed to '[)' as it is
>> now.
>
> Would that vary between range types? In other words, do I bring back
> default_flags?
>
> If not, I think a lot of people will object. The most common use-case
> for range types are for continuous ranges like timestamps. And (as I
> pointed out in reply to Florian) there are good reasons to use the '[)'
> convention for those cases.

I'm proposing it for discrete ranges.  For continuous ranges, I guess
it makes sense to have "up to, but not including".  The same boundary
inclusivity/exclusivity thing seems unintuitive for discrete ranges.
This has the downside of inconsistency, but I don't think that's
really a solid argument against it since their use will be different
anyway.

-- 
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company