linhongyu510 commented on PR #2559: URL: https://github.com/apache/age/pull/2559#issuecomment-6159665778
Re: the non-blocking question on [discussion_r4251546518](https://github.com/apache/age/pull/2559#discussion_r4251546518) — Good catch; I agree the asymmetry is real. Today the helper only inspects the top-level AND conjunction, so a `type(r) = 'P'` inside a parenthesized sub-AND (`r.v > 0 AND (type(r) = 'P' AND r.v < 4)`) is retained, while the semantically identical flat form is elided — a parentheses-dependent inconsistency, not a correctness rule. My view: making it recursion-aware is the right fix. A `type(r) = <static-label>` predication is redundant iff it sits in an AND-conjunct already satisfied by the edge's static label, regardless of parenthesization. I'd recurse into `BoolExpr`/`AND_EXPR` but deliberately stop at `OR_EXPR`/`NOT_EXPR` boundaries — crossing into an OR branch would be over-elision. This is a separate enhancement from the default-label-edge bug this PR fixes (`IS_DEFAULT_LABEL_EDGE(static_label)` guard). Happy to add it as its own commit with regress cases for nested + flat forms (and an OR-group guard case), or spin it out as a follow-up — your call. (Couldn't post inline on the thread; the org's OAuth restrictions blocked the review-comment reply.) 🤖 AI-assisted (Claude Code); assessment only, no code pushed for this suggestion. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
