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.
In response to
pgsql-hackers by date
|Next:||From: Aidan Van Dyk||Date: 2009-12-02 04:23:29|
|Subject: Re: Block-level CRC checks|
|Previous:||From: Robert Haas||Date: 2009-12-02 04:17:58|
|Subject: Re: Page-level version upgrade (was: Block-level CRC checks)|