Thread
-
Re: Row pattern recognition
Henson Choi <assam258@gmail.com> — 2026-05-09T07:43:18Z
Hi Tatsuo, Eleven incremental patches on top of v47. Patches 0001-0010 are the same set I posted on 2026-05-07, with cosmetic touches only. Patch 0011 is new and tightens the consistency of how this code base cites the SQL standard. So far I have been pushing ahead narrowly on the feature implementation itself. I am aware I still have much to learn about the PostgreSQL project's culture and conventions, and your continued guidance would be very much appreciated. Patch summary: - 0001 Add DEFINE non-volatile baseline to rpr_integration B9 Adds a STABLE/IMMUTABLE baseline ahead of the volatile case so the rejection in 0002 is visible against a working reference. - 0002 Unify RPR DEFINE walkers and reject volatile callees [A]. Collapses the four DEFINE walkers (parser / planner / executor) into one phase-tagged traversal and, on that base, rejects volatile / NextValueExpr at parse-analysis. STABLE / IMMUTABLE accepted. The offset runtime-constant check is folded in; B9 flips to error-case and its XXX is dropped. - 0003 Cover RPR empty-match path with EXPLAIN tests; fix stale XXX comments [B]. Adds rpr_explain coverage that surfaces "NFA: N matched (len 0/0/0.0)" so the NFA-found-but-empty-frame path is regression-visible; replaces stale rpr_nfa XXXs. - 0004 Reclassify DEFINE qualifier check and reword diagnostic to "expression" [D]. Tri-classifies (pattern var / range var / fall- through) so unknown qualifiers fall through to the standard "column does not exist" diagnostic. Reworded to "expression" since the quoted token may include indirection on composite types (e.g. (A.items).amount). - 0005 Sync stale comments on DEFINE/PATTERN handling validateRPRPatternVarCount() rejects DEFINE names not in PATTERN, but comments / SELECT doc described it as "collection" / "filtered during planning". Wording aligned; XXX note's "column references" bumped to "expressions" to match 0004. Comment + doc only. - 0006 Add trailing commas to RPR enum definitions Per Jian. RPRNavKind, RPRNavOffsetKind, RPRPatternNodeType. - 0007 Remove optional outer parentheses from ereport() calls in RPR files Per Jian + your gram.y patch. 19 sites in parse_rpr.c / optimizer/plan/rpr.c plus the gram.y sites. - 0008 Add high-water mark tracking to NFA visited bitmap reset [C]. Resets only the touched span (O(span_words) instead of O(numElements/64)), at the cost of two int16 comparisons per visit. Semantics unchanged; happy to drop if you prefer the simpler bulk reset. - 0009 Document DEFINE subquery rejection as intentional over-rejection Comment-only. Records that SQL/RPR permits a non-RPR, non-pattern-var-correlated subquery in DEFINE (see 0011 for the normalized citation), and that our blanket rejection is deliberate over-rejection. The case distinction (walk subquery Query for nested RPR; match ColumnRef qualifiers against ancestor p_rpr_pattern_vars) is doable with existing infrastructure and left as future work, not blocked on any other feature. - 0010 Remove duplicate #include in nodeWindowAgg.c "common/int.h" was included twice and the first occurrence was misplaced between catalog/* headers. Drops the misplaced first; the second sits at the correct alphabetical position. - 0011 Normalize SQL/RPR standard references across code, comments, and tests Doc/comment/test-header hygiene. Standardizes citations to ISO/IEC 19075-5 (SQL Technical Report Part 5, "Row pattern recognition in SQL"); earlier comments mixed bare "19075-5", "9075-2", "SQL standard", and "SQL:2016 STR06" forms. Where Chapter 4 (FROM / R010) and Chapter 6 (WINDOW / R020) describe parallel material, cites the Chapter 6 subclause first since this implementation targets R020. Pins "STR06" to its source (Subclause 7.2.8) in the rpr_nfa / rpr_explain commentary; replaces ad-hoc section / arrow glyphs with ASCII. Adds a short normative-reference paragraph to executor/README.rpr so future patches inherit the policy. Comments / docs / test headers only. Still deferred: - B7 Recursive CTE XXX: pending community input on the ISO/IEC 19075-5 6.17.5 / 4.18.5 interpretation. Best regards, Henson