On Wed, Dec 29, 2021 at 2:06 AM Peter Eisentraut <peter.eisentr...@enterprisedb.com> wrote: > Here is a rebased version of this patch.
BTScanInsertData.anynullkeys already effectively means "if the index is a unique index, then we don't actually need to go through _bt_check_unique(), or perform any other checkingunique steps". This is really an instruction about what to do (or not do), based on the specifics of the values for the insertion scan key plus the index definition. In other words, the code in _bt_mkscankey() that sets up BTScanInsertData (an insertion scankey) was written with the exact requirements of btinsert() in mind -- nothing more. I wonder if the logic for setting BTScanInsertData.anynullkeys inside _bt_mkscankey() is the place to put your test for rel->rd_index->indnullsnotdistinct -- not inside _bt_doinsert(). That would probably necessitate renaming anynullkeys, but that's okay. This feels more natural to me because a NULL key column in a NULLS NOT DISTINCT unique constraint is very similar to a NULL non-key column in an INCLUDE index, as far as our requirements go -- and so both cases should probably be dealt with at the same point. -- Peter Geoghegan
