| From: | Victor Yegorov <vyegorov(at)gmail(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Fully documenting the design of nbtree row comparison scan keys |
| Date: | 2025-10-31 09:06:45 |
| Message-ID: | CAGnEbojMjXsWjAjgQx9=baEnMEU4vhkqXR1MccjwFC-M7vzXBg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
пт, 31 окт. 2025 г. в 00:35, Peter Geoghegan <pg(at)bowt(dot)ie>:
> I didn't understand every nuance of row compare inequalities myself
> until quite recently. The rules with NULLs are particularly tricky.
>
> It seems worthwhile to clear things up now in large part due to the
> recent addition of code in places like _bt_advance_array_keys -- code
> that wants to to treat row compare keys as if they were just a simple
> scalar inequality on the row compare's most significant column. That
> general behavior isn't new (e.g., _bt_first has long ignored row
> compare scan key markings when deducing a NOT NULL constraint), but
> it's not easy to see why it's correct.
>
Greetings.
I took a look at the patch. Proposed comments look highly valuable,
especially around NULLs, doesn't look immediately obvious, so
definitely requires a comment.
Looks good to commit.
Wouldn't it be good to add such information also into the user
documentation, say into
https://www.postgresql.org/docs/current/functions-comparisons.html#ROW-WISE-COMPARISON
?
--
Victor Yegorov
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2025-10-31 09:18:05 | Re: formatting.c cleanup |
| Previous Message | Gureumi | 2025-10-31 09:03:32 | [PATCH] Fix Korean typo 'checkpoint' in log |