From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(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-11-26 07:13:43 |
Message-ID: | 1259219623.19289.502.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 therefore do 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
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2009-11-26 07:15:21 | Backup history file should be replicated in Streaming Replication? |
Previous Message | Oleg Bartunov | 2009-11-26 06:55:56 | Re: force index problem in 8.4.1 |