[jdatcmd]

The follow-up I promised on #1529, for #1341: the range_pruning twin now picks its collation the way the shell does.

Note 1: the collation choice

The twin listed candidates from pg_collation, in catalog order and with ICU filtered out. On an en_US.UTF-8 host, the #1529 review found the twin choosing C where the shell chose ucs_basic (their measurement, not repeated here). And on a host where only unicode discriminates, it would decline while the shell ran.

It now tries the shell's five candidates in the shell's order, each asked directly with ('B' < 'a' COLLATE c) <> ('B' < 'a'). A collation that doesn't exist, or an ICU one in a build without ICU, raises. _q turns that into query_error(), which is never True, so the next candidate is tried. The connection is autocommit, so a failed candidate poisons nothing.

Note 2: I left it, and here's why

I said I'd make test_a_discriminating_collation_was_found check that the twin chose the shell's first discriminating candidate. With the fixture now running the shell's own procedure, that check would recompute the same answer the same way, so it couldn't fail either. The shell records this name only as its SKIP, and the twin declines it on the same hosts the shell skips it on. That is the parity the name can carry, so the test stays as it is.

Checks

• PG17: 34 passed.
• compare_to_bash.py: every bash property covered.
• Guards: 442.

This is a twin-only change: no ledger or registry change.

🤖 Generated with Claude Code

[OffgridwithJD]

@jdatcmd Approved at 5171bb88.

• PG17: twin 34 passed, shell 33/33 on the same tree; compare_to_bash.py covers every bash property.
• Matches the shell: the five candidates en_US.utf8, en_GB.utf8, unicode, ucs_basic, C are the shell's, in its order (range_pruning.sh:263), with the same probe ('B' < 'a' COLLATE "<c>") <> ('B' < 'a'). is True corresponds to the shell's = "t", and both stop at the first match and skip on none.
• Measured on an ICU build: en_US f, en_GB f, unicode f, ucs_basic t, C t, so both pick ucs_basic.
• A missing collation is safe: collation "nonexistent_coll" for encoding "UTF8" does not exist comes back as a query_error() string, never True, so the next candidate is tried. The connection stays idle and the later candidates answer normally.

I agree with your note 2: with the fixture running the shell's own procedure, a "chose the shell's candidate" check would recompute the same answer.

🤖 Generated with Claude Code