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

From Peter Eisentraut
Subject Re: UNIQUE null treatment option
Date
Msg-id ac7f9f56-acf6-dfd2-2295-56eff1bbc935@enterprisedb.com
Whole thread Raw
In response to UNIQUE null treatment option  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: UNIQUE null treatment option  (Pavel Borisov <pashkin.elfe@gmail.com>)
Re: UNIQUE null treatment option  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
Here is a rebased version of this patch.

On 27.08.21 14:38, Peter Eisentraut wrote:
> The SQL standard has been ambiguous about whether null values in
> unique constraints should be considered equal or not.  Different
> implementations have different behaviors.  In the SQL:202x draft, this
> has been formalized by making this implementation-defined and adding
> an option on unique constraint definitions UNIQUE [ NULLS [NOT]
> DISTINCT ] to choose a behavior explicitly.
> 
> This patch adds this option to PostgreSQL.  The default behavior
> remains UNIQUE NULLS DISTINCT.  Making this happen in the btree code
> is apparently pretty easy; most of the patch is just to carry the flag 
> around to all the places that need it.
> 
> The CREATE UNIQUE INDEX syntax extension is not from the standard,
> it's my own invention.
> 
> (I named all the internal flags, catalog columns, etc. in the
> negative ("nulls not distinct") so that the default PostgreSQL
> behavior is the default if the flag is false.  But perhaps the double
> negatives make some code harder to read.)

Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Converting WAL to SQL
Next
From: Anton Voloshin
Date:
Subject: [PATCH] allow src/tools/msvc/*.bat files to be called from the root of the source tree