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

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