Re: UNIQUE null treatment option

On 13.01.22 19:36, Peter Geoghegan wrote:
> 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.

Makes sense.  Here is an updated patch with this change.

I didn't end up renaming anynullkeys.  I came up with names like 
"anyalwaysdistinctkeys", but in the end that felt too abstract, and 
moreover, it would require rewriting a bunch of code comments that refer 
to null values in this context.  Since as you wrote, anynullkeys is just 
a local concern between two functions, this slight inaccuracy is perhaps 
better than some highly general but unclear terminology.