Re: Comments on Exclusion Constraints and related datatypes

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Comments on Exclusion Constraints and related datatypes
Date: 2010-03-22 14:28:10
Message-ID: 1269268090.8481.608.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2010-03-22 at 10:13 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> > * Exclusion indexes are created with the suffix "_exclusion". That's a
> > very long suffix and will overflow most defined reports/screens. It
> > would be much better to use just "_excl",
>
> No particular objection here.

OK, will change.

> > * Circles, Boxes and other geometric datatypes defined "overlaps" to
> > include touching shapes. So
> > SELECT circle '((0,0), 1)' && circle '((2,0),1)';
> > is true, which is fairly strange and makes those datatypes very counter
> > intuitive. Considering they are instructional aids, this is bad.
>
> You're approximately twenty years too late to propose changing that,
> even if it were clearly a good idea which I doubt.

Possibly. We should at least document that.

> > Also, if the only common sense usage of exclusion constraints is GIST,
> > why does the syntax default to "btree"?
>
> Since your "if" isn't a correct statement, the complaint doesn't follow.

Docs say
"The access method must support amgettuple (see Chapter 51); at present
this means GIN cannot be used. Although it's allowed, there is little
point in using btree or hash indexes with an exclusion constraint,
because this does nothing that an ordinary unique constraint doesn't do
better. So in practice the access method will always be GiST."

Hence my comment.

--
Simon Riggs www.2ndQuadrant.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2010-03-22 14:35:03 Re: proposal: more practical view on function's source code
Previous Message Tom Lane 2010-03-22 14:15:18 Re: ALTER TABLE .... make constraint DEFERRABLE