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