Re: UNIQUE null treatment option - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: UNIQUE null treatment option
Date
Msg-id 12facb9f-541b-5a5c-040e-a5ca3c1dd4a3@enterprisedb.com
Whole thread Raw
In response to Re: UNIQUE null treatment option  (Pavel Borisov <pashkin.elfe@gmail.com>)
List pgsql-hackers
On 28.01.22 13:56, Pavel Borisov wrote:
>     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.
> 
> Agree with that. With the comment it is clear how it works.
> 
> I've looked at the patch v3. It seems good enough for me. CFbot tests 
> have also come green.
> Suggest it is RFC now.

Committed.  Thanks.



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Design of pg_stat_subscription_workers vs pgstats
Next
From: Amit Kapila
Date:
Subject: Re: Bugs in pgoutput.c