Re: Range Types - typo + NULL string constructor

Florian G. Pflug <fgp@phlo.org>

From: Florian Pflug <fgp@phlo.org>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Thom Brown <thom@linux.com>, Robert Haas <robertmhaas@gmail.com>, Erik Rijkers <er@xs4all.nl>, pgsql-hackers@postgresql.org
Date: 2011-10-11T01:26:01Z
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 Oct10, 2011, at 19:41 , Jeff Davis wrote:
> On Mon, 2011-10-10 at 19:22 +0200, Florian Pflug wrote:
>> I still think we should strive for consistency here, so let's also make
>> '[]' the default flags for the range constructors.
> 
> For continuous ranges I don't think that's a good idea. Closed-open is a
> very widely-accepted convention and there are good reasons for it -- for
> instance, it's good for specifying contiguous-but-non-overlapping
> ranges.

It really depends on what you're using ranges for. Yeah, if you're "convering"
something with ranges (like mapping things to a certain period of time, or
an area of space), then half-open ranges are probably very common.

If, OTOH, you're storing measurement with error margins, then open ranges,
i.e. '()', are probably what you want.

I still firmly believe that consistency trumps convenience here. Specifying
the range boundaries' exclusivity/inclusivity explicitly is quite cheap...

> So, I think we either need to standardize on '[)' or allow different
> default_flags for different types. Or, always specify the inclusivity in
> the constructor (hopefully in a convenient way).

In the light of Tom's argument, my pick would be '[]'. It's seem strange
to normalize ranges over discrete types to closed ranges, yet make the
construction function expect open boundaries by default.

best regards,
Florian Pflug