Re: UNIQUE null treatment option
| От | Peter Eisentraut |
|---|---|
| Тема | Re: UNIQUE null treatment option |
| Дата | |
| Msg-id | 12facb9f-541b-5a5c-040e-a5ca3c1dd4a3@enterprisedb.com обсуждение |
| Ответ на | Re: UNIQUE null treatment option (Pavel Borisov <pashkin.elfe@gmail.com>) |
| Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: