Re: Exclusion constraints on partitioned tables

On 1/24/23 06:38, Ronan Dunklau wrote:
> I've taken a look at the patch, and I'm not sure why you keep the restriction
> on the Gist operator being of the RTEqualStrategyNumber strategy. I don't
> think  we have any other place where we expect those strategy numbers to
> match. For hash it's different, as the hash-equality is the only operator
> strategy and as such there is no other way to look at it. Can't we just
> enforce partition_operator == exclusion_operator without adding the
> RTEqualStrategyNumber for the opfamily into the mix ?

Thank you for taking a look! I did some research on the history of the 
code here, and I think I understand Tom's concern about making sure the 
index uses the same equality operator as the partition. I was confused 
about his remarks about the opfamily, but I agree with you that if the 
operator is the same, we should be okay.

I added the code about RTEqualStrategyNumber because that's what we need 
to find an equals operator when the index is GiST (except if it's using 
an opclass from btree_gist; then it needs to be BTEqual again). But then 
I realized that for exclusion constraints we have already figured out 
the operator (in RelationGetExclusionInfo) and put it in 
indexInfo->ii_ExclusionOps. So we can just compare against that. This 
works whether your index uses btree_gist or not.

Here is an updated patch with that change (also rebased).

I also included a more specific error message. If we find a matching 
column in the index but with the wrong operator, we should say so, and 
not say there is no matching column.

Thanks,

-- 
Paul              ~{:-)
pj@illuminatedcomputing.com