On Mon, 2010-03-22 at 10:13 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.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