Re: operator exclusion constraints
От | Robert Haas |
---|---|
Тема | Re: operator exclusion constraints |
Дата | |
Msg-id | 603c8f070912012019k6824f672o6b805f08866a0a54@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: operator exclusion constraints (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: operator exclusion constraints
|
Список | 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 по дате отправления: