Re: Comments on Exclusion Constraints and related datatypes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Comments on Exclusion Constraints and related datatypes
Date
Msg-id 19238.1269268659@sss.pgh.pa.us
Whole thread Raw
In response to Re: Comments on Exclusion Constraints and related datatypes  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> On Mon, 2010-03-22 at 10:13 -0400, Tom Lane wrote:
>>> 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."

Well, I would hope that the lack of GIN support will be cured someday.
I see the above as a statement of what's true in 9.0, not what will
always be true; so it's pretty weak as a justification for introducing a
confusing default behavior.

Actually the statement might be overly strong even now.  If you want
uniqueness checks with a hash index, exclusion is the only way to get
that.  I'm not sure that that's actually useful versus a standard btree
unique constraint, but it's at least arguably another use case.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: more practical view on function's source code
Next
From: Peter Eisentraut
Date:
Subject: Re: Comments on Exclusion Constraints and related datatypes