Re: operator exclusion constraints

On Tue, 2009-11-17 at 23:13 -0500, Robert Haas wrote:
> Forgive me if this is discussed before, but why does this store the
> strategy numbers of the relevant operators instead of the operators
> themselves?  It seems like this could lead to surprising behavior if
> the user modifies the definition of the operator class.

Still open.

> I'm wondering if we can't use the existing
> BuildIndexValueDescription() rather than the new function
> tuple_as_string().  I realize there are two tuples, but maybe it makes
> sense to just call it twice?

Changed.

> I'm attaching a revised doc patch for your consideration.

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.

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

Regards,
	Jeff Davis