Incremental Update: Proposal for Centralized DefElem Option Handling
A new participant (Thom) raises an architectural question about the root cause of the duplicate-option bug: the lack of shared infrastructure for parsing DefElem option lists across commands.
The Proposal
Thom observes that REPACK, VACUUM, and EXPLAIN all independently implement the same boilerplate pattern for processing parenthesized option lists:
- Iterate over a
DefElemlist - Reject unknown option names
- Coerce values via
defGetBoolean()(or similar) - Apply last-duplicate-wins semantics for repeated options
Each command currently writes its own version of this loop, which is how the REPACK bug (OR-accumulate instead of overwrite) slipped in. Thom proposes a common utility routine that accepts:
- A
DefElemlist - A table of valid option names and their expected types
The routine would handle iteration, unknown-option rejection, type coercion, and last-wins semantics generically. Command-specific semantic validation (e.g., conflicting option combinations) would remain in command code.
Response from Álvaro Herrera
Álvaro's response is brief and neutral — he notes the options differ per command but invites a patch if Thom sees room for improvement. No objection to the concept, but no endorsement either.
Assessment
This is a reasonable refactoring idea that addresses the structural cause of the class of bugs discovered in this thread. However, Thom self-defers it ("probably something for later" given the dev cycle timing), so no patch is forthcoming immediately. The idea is architecturally sound but represents future work, not active development.