src/backend/optimizer/plan/rpr.c

Confirmed defensive-unreachable.
RPRPatternNodeType (parsenodes.h:615-621) has exactly four values:
RPR_PATTERN_VAR, RPR_PATTERN_SEQ, RPR_PATTERN_ALT, RPR_PATTERN_GROUP.
The switch at rpr.c:118-127 handles all four and every case ends in a return (VAR returns strcmp;
SEQ/ALT/GROUP share the rprPatternChildrenEqual return).
Control therefore can never fall through to pg_unreachable() at line 129. Every assignment to ->nodeType in the backend (gram.y:17652/17684/17713/17726/21425/21484) uses one of the four valid constants, set only by the grammar;
nothing can inject a fifth value, and the node tree is never constructed with an uninitialized nodeType reachable from SQL.
The two early-return guards (a->nodeType != b->nodeType, etc.) further mean a is always inspected with a valid value.
No SQL or regression input can drive line 129. The claim's root cause is accurate.

Keep as-is. pg_unreachable() is the standard PostgreSQL idiom for an exhaustive enum switch and correctly documents that control cannot reach here.
Optionally the trailing "return false;
" is only present to satisfy compilers that do not treat pg_unreachable() as noreturn;
no functional change is warranted.
No source change needed.

Confirmed unreachable.
The switch at rpr.c:956 enumerates all four members of RPRPatternNodeType (RPR_PATTERN_VAR/SEQ/ALT/GROUP, parsenodes.h:617-620) and every case ends in a return, so control falls through to pg_unreachable() at line 968 only if pattern->nodeType holds a value outside the enum. nodeType is set exclusively by the parser when building the pattern tree (always a valid member), and under -DWRITE_READ_PARSE_PLAN_TREES the round-trip uses WRITE_ENUM_FIELD/READ_ENUM_FIELD (outfuncs.funcs.c:1131, readfuncs.funcs.c:1296), which serializes and restores the identical integer it was given.
No SQL or regression input can inject an out-of-range nodeType.
I tried to refute via the read path (deserialization) and the parser path;
both only yield the four valid values.
The Assert(pattern != NULL) and check_stack_depth above are unrelated to line 968.

Keep as-is.
The pg_unreachable() + return is the standard PostgreSQL exhaustive-switch guard.
No change needed;
this line should be excluded from coverage expectations.

Confirmed unreachable via any SQL/regression input. getVarIdFromPattern has a single call site (rpr.c:1187) inside fillRPRPatternVar, passing node->varName from a RPR_PATTERN_VAR node. buildRPRPattern (rpr.c:1929-1942) builds one optimized tree, scans it in pass 1 (scanRPRPattern -> scanRPRPatternRecursive), then fills the SAME tree in pass 2 (fillRPRPattern).
In pass 1, every RPR_PATTERN_VAR node unconditionally appends its varName to varNames (rpr.c:1046) unless already present (rpr.c:1036), and the switch recurses identically into SEQ/GROUP/ALT children. makeRPRPattern (rpr.c:1144-1146) copies all numVars names.
Thus when pass 2 reaches a VAR node, its name is guaranteed already in pat->varNames, so the loop at 1164 always returns before line 1171. Hitting 1171 would require a VAR node in the fill pass that was absent from the scan pass;
since both passes traverse the identical optimized pointer with no intervening mutation or re-optimization, this cannot occur.
I attempted to refute by looking for a tree-shape mismatch or a VAR introduced after scanning -- none exists.
This is a legitimate internal-invariant guard.

Keep the elog(ERROR) as an internal-error consistency guard followed by pg_unreachable();
no behavioral change.
Downgrading to Assert is possible but elog provides a safer hard-failure for production builds where Asserts are compiled out, so the current code is appropriate.
Marking the line as deliberately uncovered (or wrapping with a coverage-exclusion comment) is the only reasonable action.

Confirmed defensive-unreachable.
The switch at rpr.c:1405 dispatches on RPRPatternNode->nodeType, whose type RPRPatternNodeType (parsenodes.h:615-621) is an enum with exactly four values:
RPR_PATTERN_VAR, RPR_PATTERN_SEQ, RPR_PATTERN_ALT, RPR_PATTERN_GROUP.
All four are handled by case labels at lines 1407/1415/1418/1421, and every branch returns unconditionally (no break/fall-through).
I checked every site that sets nodeType (gram.y:17652/17684/17713/17726/21425/21484 and the makeRPR* helpers) and each assigns one of the four valid values.
There is no makeNode/palloc0 path that leaves nodeType zero-initialized to an out-of-enum sentinel before it reaches fillRPRPattern;
the parser always populates it.
Therefore the fall-through pg_unreachable() at line 1425 can only fire on memory corruption or an enum extension never produced by any SQL/regression input.
No input reaches it.

Keep as-is.
The pg_unreachable() following an exhaustive enum switch is the standard PostgreSQL idiom for an exhaustive-switch guard and silences compiler warnings about missing return.
No change needed.