Re: operator exclusion constraints

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: operator exclusion constraints
Date: 2009-12-02 04:19:00
Message-ID: 603c8f070912012019k6824f672o6b805f08866a0a54@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 27, 2009 at 10:18 PM, Jeff Davis <pgsql(at)j-davis(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Aidan Van Dyk 2009-12-02 04:23:29 Re: Block-level CRC checks
Previous Message Robert Haas 2009-12-02 04:17:58 Re: Page-level version upgrade (was: Block-level CRC checks)