Re: operator exclusion constraints

On Thu, Nov 26, 2009 at 4:33 AM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> Thanks, I applied it. The only significant thing I changed was that I
> did not inline the "index_elem" because it made it fairly hard to read.
> Instead, I renamed it "exclude_elem" to make it a little more
> meaningful, which I assume may have been your motivation for inlining
> it.

No, it was really just that I didn't see any point in defining a token
that was only used in one place. It seems like it just represents a
jumble of tokens without any real connection between them, so I didn't
really see why we should break out that piece as opposed to anything
else.

> Changes this patch:
>  * doc changes
>  * changed constraint violation message to be more like btree unique
>   violation
>  * improved error message when an operator is specified that doesn't
>   have a search strategy
>
> Remaining issues:
>  * represent operator IDs in catalog, rather than strategy numbers
>  * if someone thinks it's an issue, support search strategies that
>   require binary-incompatible casts of the inputs

I'm (still) not an expert on this topic, but here's one more thought:
maybe we should try to set this up so that it works in any situation
in which an opclass itself would work. IOW, if you manage to define
an opclass, you should probably be able to define an
operator-exclusion constraint against it, rather than having some
opclasses work and others arbitrarily fail.

Just my $0.02,

...Robert