Skip site navigation (1) Skip section navigation (2)

Re: Range Types - symmetric

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Christopher Browne <cbbrowne(at)gmail(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Range Types - symmetric
Date: 2011-09-24 14:49:54
Message-ID: 201109241449.p8OEnsh26358@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Jeff Davis wrote:
> On Tue, 2011-09-13 at 12:34 -0400, Christopher Browne wrote:
> > > select int4range(5,2);
> > > ERROR:  range lower bound must be less than or equal to range upper bound
> > >
> > > Of course, I won't argue this is a bug, but I was wondering if it wouldn't be handy to allow a
> > > 'symmetric' mode in range construction, where, if the first of the pair is higher than the second,
> > > they are automatically swapped, similar to SYMMETRIC in the BETWEEN clause.
> 
> ...
> 
> > If you have a computation that gets a "backwards" range, then it is
> > more than possible that what you've got isn't an error of getting the
> > range backwards, but rather the error that your data is
> > overconstraining, and that you don't actually have a legitimate range.
> 
> Agreed. On balance, it's just as likely that you miss an error as save a
> few keystrokes.
> 
> I'll add that it would also cause a little confusion with inclusivity.
> What if you do: '[5,2)'::int4range? Is that really '[2,5)' or '(2,5]'?

Reminder:  BETWEEEN supports the SYMMETRIC keyword, so there is
a precedent for this.

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

In response to

Responses

pgsql-hackers by date

Next:From: Tatsuo IshiiDate: 2011-09-24 15:05:41
Subject: Re: unite recovery.conf and postgresql.conf
Previous:From: Bruce MomjianDate: 2011-09-24 14:43:52
Subject: Re: fix for pg_upgrade

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group