Re: Comments on Exclusion Constraints and related datatypes

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

Simon Riggs <simon(at)2ndQuadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2010-03-22 14:40:04 Re: Comments on Exclusion Constraints and related datatypes
Previous Message Pavel Stehule 2010-03-22 14:35:03 Re: proposal: more practical view on function's source code