Re: UNIQUE null treatment option

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

Re: UNIQUE null treatment option

> > 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

Re: UNIQUE null treatment option

Since cfbot did failed with error, probably, unrelated to the patch itself (see https://cirrus-ci.com/task/5330150500859904) and repeated check did not start automatically, I reattach patch v3 to restart cfbot on this patch. -- Best regards, Maxim Orlov.

Re: UNIQUE null treatment option

H v3] Add UNIQUE null treatment option 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-de

Re: UNIQUE null treatment option

> > I wonder if the logic for setting BTScanInsertData.anynullkeys inside > _bt_mkscankey() is the place to put your test for > rel->rd_index->indnullsnotdistinct -- not inside _bt_doinsert(). That > would probably necessitate renaming anynullkeys, but that's okay. This > feels more natural to me

Re: UNIQUE null treatment option

On Thu, Jan 13, 2022 at 10:36 AM Peter Geoghegan wrote: > I wonder if the logic for setting BTScanInsertData.anynullkeys inside > _bt_mkscankey() is the place to put your test for > rel->rd_index->indnullsnotdistinct -- not inside _bt_doinsert(). That > would probably necessitate renaming

Re: UNIQUE null treatment option

On Wed, Dec 29, 2021 at 2:06 AM Peter Eisentraut wrote: > Here is a rebased version of this patch. BTScanInsertData.anynullkeys already effectively means "if the index is a unique index, then we don't actually need to go through _bt_check_unique(), or perform any other checkingunique steps".

Re: UNIQUE null treatment option

I find this patch useful. It includes changes in documentation and tests. Code itself looks reasonable to me. Since, unique constraint check is done by corresponding btree index, it makes this feature implementation elegant and lightweight. In my view, it is sufficient that heap relation can have

Re: UNIQUE null treatment option

+1 for commiting this feature. Consider this useful. -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com

Re: UNIQUE null treatment option

Hi, boolisunique; + boolnulls_not_distinct; } BTSpool; Looking at the other fields in BTSpool, there is no underscore in field name. I think the new field can be named nullsdistinct. This way, the double negative is avoided. Similar comment for new fields in BTShared and

Re: UNIQUE null treatment option

CH v2] Add UNIQUE null treatment option 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

Re: UNIQUE null treatment option

On 27.08.21 14:44, Marko Tiikkaja wrote: On Fri, Aug 27, 2021 at 3:38 PM Peter Eisentraut > wrote: In the SQL:202x draft, this has been formalized by making this implementation-defined and adding an option on unique constraint definitions

Re: UNIQUE null treatment option

On Fri, Aug 27, 2021 at 3:38 PM Peter Eisentraut < peter.eisentr...@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

UNIQUE null treatment option

g is false. But perhaps the double negatives make some code harder to read.) From 14bd23b4f164c4298262e7fbfec1a49292d16e27 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Fri, 27 Aug 2021 14:31:46 +0200 Subject: [PATCH] Add UNIQUE null treatment option The SQL standard has been ambiguous about wh