Re: operator exclusion constraints
От | Jeff Davis |
---|---|
Тема | Re: operator exclusion constraints |
Дата | |
Msg-id | 1259378300.19289.683.camel@jdavis обсуждение исходный текст |
Ответ на | Re: operator exclusion constraints (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: operator exclusion constraints
|
Список | pgsql-hackers |
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 %%) Regards, Jeff Davis
Вложения
В списке pgsql-hackers по дате отправления: