> On Jan 28, 2026, at 14:14, Chao Li <[email protected]> wrote: > > Hi Hackers, > > While working on the patch [1], I was looking at the handling of > AT_AddIndexConstraint in ATPrepCmd(): > ``` > ATPrepCmd() > { > case AT_AddIndexConstraint: /* ADD CONSTRAINT USING INDEX */ > ATSimplePermissions(cmd->subtype, rel, ATT_TABLE | > ATT_PARTITIONED_TABLE); > /* This command never recurses */ > /* No command-specific prep needed */ > pass = AT_PASS_ADD_INDEXCONSTR; > } > ``` > > I initially thought the comment about “never recurses” was stale, but after > some debugging, I found that this branch is actually unreachable. So leaving > the code and comments in an unreachable branch would be confusing for readers. > > This patch cleans up the handling by putting an Assert(false) there and > adding a comment to explain why this code path is unreachable. I did think > about just deleting the branch, but decided to keep it: if it were removed > entirely, readers might wonder why AT_AddIndexConstraint is not handled in > ATPrepCmd() and end up spending time debugging this themselves. >
I thought over and decided to delete AT_AddIndexConstraint from ATPrepCmd, which should be cleaner. PFA v2: * Deleted AT_AddIndexConstraint from ATPrepCmd * Added a comment under AT_AddConstraint to explain how AT_AddIndexConstraint is handled Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
v2-0001-tablecmds-cleanup-unreachable-AT_AddIndexConstrai.patch
Description: Binary data
