| From: | Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
| Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: UNIQUE null treatment option |
| Date: | 2022-01-28 12:56:11 |
| Message-ID: | CALT9ZEHV1uQZzLY=adSF5Bhfj3DaSLCZRmUJCSF=5F0EjV5cUw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> 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.
--
Best regards,
Pavel Borisov
Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hamid Akhtar | 2022-01-28 13:40:20 | Re: Parameter for planner estimate of recursive queries |
| Previous Message | Fabrice Chapuis | 2022-01-28 11:35:30 | Re: Logical replication timeout problem |