Re: Range Types - typo + NULL string constructor
David Fetter <david@fetter.org>
From: David Fetter <david@fetter.org>
To: Florian Pflug <fgp@phlo.org>
Cc: Jeff Davis <pgsql@j-davis.com>, Thom Brown <thom@linux.com>, Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Erik Rijkers <er@xs4all.nl>, pgsql-hackers@postgresql.org
Date: 2011-10-11T13:28:30Z
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 Tue, Oct 11, 2011 at 03:20:05PM +0200, Florian Pflug wrote: > On Oct11, 2011, at 14:43 , David Fetter wrote: > > I'd recoil at not having ranges default to left-closed, > > right-open. The use case for that one is so compelling that I'm > > OK with making it the default from which deviations need to be > > specified. > > The downside of that is that, as Tom pointed out upthread, we cannot > make [) the canonical representation of ranges. It'd require us to > increment the right boundary of a closed range, but that incremented > boundary might no longer be in the base type's domain. > > So we'd end up with [) being the default for range construction, but > [] being the canonical representation, i.e. what you get back when > SELECTing a range (over a discrete base type). > > Certainly not the end of the world, but is the convenience of being > able to write somerange(a, b) instead of somerange(a, b, '[)') > really worth it? I kind of doubt that... You're making a persuasive argument for the latter based solely on the clarity. If people see that 3rd element in the DDL, or need to provide it, it's *very* obvious what's going on. Cheers, David (who suspects that having a syntax like somerange[a,b) just won't work with the current state of parsers, etc.) -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate