Re: operator exclusion constraints

On Wed, Nov 18, 2009 at 9:00 AM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> I'm in Tokyo right now, so please excuse my abbreviated reply.
>
> On Tue, 2009-11-17 at 23:13 -0500, Robert Haas wrote:
>> Forgive me if this is discussed before, but why does this store the
>> strategy numbers of the relevant operators instead of the operators
>> themselves?
>
> At constraint definition time, I need to make sure that the strategy
> numbers can be identified anyway, so it wouldn't save any work in
> ATAddOperatorExclusionConstraint. At the time it seemed slightly more
> direct to use strategy numbers in index_check_constraint, but it's
> probably about the same.

It sets off a red flag for me any time I see code that asks for A from
the user and then actually stores B under the hood, for fear that the
relationship that A and B might change. However...

>> It seems like this could lead to surprising behavior if
>> the user modifies the definition of the operator class.
>
> Right now, operator classes can't be modified in any meaningful way. Am
> I missing something?

...poking at it, I have to agree that at least as things stand right
now, I can't find a way to break it. Not sure if it's future-proof.

>> I'm wondering if we can't use the existing
>> BuildIndexValueDescription() rather than the new function
>> tuple_as_string().  I realize there are two tuples, but maybe it makes
>> sense to just call it twice?
>
> Are you suggesting I change the error output, or reorganize the code to
> try to reuse BuildIndexValueDescription, or both?

I was thinking maybe you call BuildIndexValueDescription twice and
make the error message say something like <output of first call>
conflicts with <output of second call>.

One other thing I noticed tonight while poking at this. If I install
contrib/citext, I can do this:

create table test (a citext, exclude using hash (a with =));

But if I install contrib/intarray, I can't do this:

create table test (a int4[], exclude using gist (a with =));
ERROR: operator does not exist: integer[] = integer[]

Not sure if I'm doing something wrong, or if this is a limitation of
the design, or if it's a bug, but it seems strange. I'm guessing it's
because intarray uses the anyarray operator rather than a dedicated
operator for int[], but it seems like that ought to work.

...Robert