Guancheng Luo <prajnam...@gmail.com> writes: > I found that things could go wrong in some cases, when the unique index and > the partition key use different opclass.
I agree that this is an oversight, but it seems like your solution is overcomplicated and probably still too forgiving. Should we not just insist that the index opfamily match the partition key opfamily? It looks to me like that would reduce the code change to about like this: - if (key->partattrs[i] == indexInfo->ii_IndexAttrNumbers[j]) + if (key->partattrs[i] == indexInfo->ii_IndexAttrNumbers[j] && + key->partopfamily[i] == get_opclass_family(classObjectId[j])) which is a lot more straightforward and provides a lot more certainty that the index will act as the partition constraint demands. This would reject, for example, a hash index associated with a btree-based partition constraint, but I'm not sure we're losing anything much thereby. (I do not think your patch is correct for the case where the opfamilies belong to different AMs, anyway.) I'm not really on board with adding a whole new test script for this, either. regards, tom lane