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

From Peter Eisentraut
Subject Re: UNIQUE null treatment option
Date
Msg-id 29632a11-25da-c073-4e89-3eec6315b102@enterprisedb.com
Whole thread Raw
In response to Re: UNIQUE null treatment option  (Marko Tiikkaja <marko@joh.to>)
List pgsql-hackers
On 27.08.21 14:44, Marko Tiikkaja wrote:
> On Fri, Aug 27, 2021 at 3:38 PM Peter Eisentraut 
> <peter.eisentraut@enterprisedb.com 
> <mailto:peter.eisentraut@enterprisedb.com>> wrote:
> 
>     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.
> 
>     The CREATE UNIQUE INDEX syntax extension is not from the standard,
>     it's my own invention.
> 
> 
> For the unique index syntax, should this be selectable per 
> column/expression, rather than for the entire index as a whole?

Semantically, this would be possible, but the bookkeeping to make it 
work seems out of proportion with the utility.  And you'd have the 
unique index syntax out of sync with the unique constraint syntax, which 
would be pretty confusing.



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Non-decimal integer literals
Next
From: Bharath Rupireddy
Date:
Subject: Re: What are exactly bootstrap processes, auxiliary processes, standalone backends, normal backends(user sessions)?