Guancheng Luo <prajnamort@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