Re: Fully documenting the design of nbtree row comparison scan keys - Mailing list pgsql-hackers

From Victor Yegorov
Subject Re: Fully documenting the design of nbtree row comparison scan keys
Date
Msg-id CAGnEbojMjXsWjAjgQx9=baEnMEU4vhkqXR1MccjwFC-M7vzXBg@mail.gmail.com
Whole thread Raw
In response to Fully documenting the design of nbtree row comparison scan keys  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
пт, 31 окт. 2025 г. в 00:35, Peter Geoghegan <pg@bowt.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

pgsql-hackers by date:

Previous
From: Gureumi
Date:
Subject: [PATCH] Fix Korean typo 'checkpoint' in log
Next
From: Peter Eisentraut
Date:
Subject: Re: formatting.c cleanup