> On Mar 26, 2020, at 01:00, Tom Lane <t...@sss.pgh.pa.us> wrote: > > 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.)
Since unique index cannot be using HASH, I think we only need to consider BTREE index here. There is cases when a BTREE index associated with a HASH partition key, but I think we should allow them, as long as their equality operators consider the same value as equal. I’ve added some more test for this case. > I'm not really on board with adding a whole new test script for this, > either. Indeed, I think `indexing.sql` might be more apporiate. I moved these tests in my new patch.
0001-Check-operator-when-creating-UNIQUE-index-on-PARTITI.patch
Description: Binary data
Best Regards, Guancheng Luo
