Re: operator exclusion constraints - Mailing list pgsql-hackers

From Robert Haas
Subject Re: operator exclusion constraints
Date
Msg-id 603c8f070912012019k6824f672o6b805f08866a0a54@mail.gmail.com
Whole thread Raw
In response to Re: operator exclusion constraints  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: operator exclusion constraints  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On Fri, Nov 27, 2009 at 10:18 PM, Jeff Davis <pgsql@j-davis.com> wrote:
> On Thu, 2009-11-26 at 01:33 -0800, Jeff Davis wrote:
>> Remaining issues:
>>  * represent operator IDs in catalog, rather than strategy numbers
>
> Done, attached.
>
>>  * if someone thinks it's an issue, support search strategies that
>>    require binary-incompatible casts of the inputs
>
> I've already solved the original problem involving ANYARRAY. If someone
> comes up with a good use case, or provides me with a little more
> guidance, I'll reconsider this problem again. Otherwise, I feel like I'm
> solving a problem that doesn't exist (after all, none of the contrib
> modules seem to have a problem with the current assumptions, nor does
> postgis, nor does my PERIOD module). So, I'm considering this a
> "non-issue" until further notice.
>
> To summarize, the problem as I understand it is this:
>
> You have two types, T1 and T2, and there's an implicit cast (with
> function or with inout) from T1 to T2. And you have an opclass like:
>
> CREATE OPERATOR CLASS t1_ops FOR TYPE t1
> ...
>  OPERATOR 17 %%(t2, t2)
> ...
>
> And then you have an exclusion constraint like:
> CREATE TABLE foo
> (
>  a t1,
>  EXCLUDE (a t1_ops WITH %%)
> );
>
> What should the behavior be in the following two cases?
>  1. Only operator %%(t2, t2) exists.
>  2. Operator %%(t1, t1) and %%(t2, t2) exist.
>
> If left unsolved, #1 results in an error because the operator requires
> binary-incompatible coercion. #2 results in an error because %%(t1, t1)
> is not in the opclass.
>
> Arguably either one of them could succeed by finding %%(t2, t2) and
> performing the appropriate conversion; but I think it's fair to just say
> "the opclass is poorly defined".
>
> Note that if the opclass is on type t2, you can simply cast "a" to t2
> explicitly in the expression, like so:
>  EXCLUDE((a::t2) t2_ops WITH %%)

For parity with unique constraints, I think that the message:

operator exclusion constraint violation detected: %s

should be changed to:

conflicting key value violates operator exclusion constraint "%s"

In ATAddOperatorExclusionConstraint, "streatagy" is misspelled.

Other than that, it looks good to me.

...Robert


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Page-level version upgrade (was: Block-level CRC checks)
Next
From: "Joshua D. Drake"
Date:
Subject: Re: SE-PgSQL patch review