Re: UNIQUE null treatment option

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>

To: Pavel Borisov <pashkin.elfe@gmail.com>

Cc: Peter Geoghegan <pg@bowt.ie>, pgsql-hackers <pgsql-hackers@postgresql.org>

Date: 2022-02-03T10:54:10Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Add UNIQUE null treatment option
- 94aa7cc5f707 15.0 landed

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.