Re: operator exclusion constraints
От | Jeff Davis |
---|---|
Тема | Re: operator exclusion constraints |
Дата | |
Msg-id | 1259219623.19289.502.camel@jdavis обсуждение исходный текст |
Ответ на | Re: operator exclusion constraints (Jeff Davis <pgsql@j-davis.com>) |
Список | pgsql-hackers |
On Wed, 2009-11-25 at 15:59 -0800, Jeff Davis wrote: > > My operator-class-fu is insufficient to render judgment on this point. > > I think the thing to do is look at a bunch of non-built-in opclasses > > and check for POLA violations. > > Ok, I'll consider this more. In cases where the operator class type is different from the search operator's operands' types, one of the following is usually true: * There is a binary cast from the opclass type (same as expression type) to the search operator's operands' types, or it is otherwise compatible (e.g. ANYARRAY).* There is a candidate function that's a better match (e.g. there may be an =(int8, int8) on int2_ops, but there's also =(int2, int2)).* The left and right operand types are different, and thereforedo not work with operator exclusion constraints anyway (e.g. full text search @@). After installing all contrib modules, plus my period module, and postgis, there appear to be no instances that violate these assumptions (according to a join query and some manual testing). In theory there could be, however. It's kind of ugly to make it work, and a challenge to test it, so for now I'll only accept operators returned by compatible_oper(). If you disagree, I can make it work. Regards,Jeff Davis
В списке pgsql-hackers по дате отправления: