| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | Marko Tiikkaja <marko(at)joh(dot)to> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: UNIQUE null treatment option |
| Date: | 2021-09-07 11:17:40 |
| Message-ID: | 29632a11-25da-c073-4e89-3eec6315b102@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 27.08.21 14:44, Marko Tiikkaja wrote:
> On Fri, Aug 27, 2021 at 3:38 PM Peter Eisentraut
> <peter(dot)eisentraut(at)enterprisedb(dot)com
> <mailto:peter(dot)eisentraut(at)enterprisedb(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2021-09-07 11:22:27 | Re: What are exactly bootstrap processes, auxiliary processes, standalone backends, normal backends(user sessions)? |
| Previous Message | Peter Eisentraut | 2021-09-07 11:13:10 | Re: Non-decimal integer literals |