Hi Tatsuo,
Thanks for the review. Both points addressed in the attached
0013 v2; 0012/0014/0015 are unchanged from the 2026-05-12 set
and re-attached for convenience.
I think removing the exiting comment ("For WITH RECURSIVE, we rearrange
> the list elements...") is not appropriate as this explains subsequent
> process, which is not changed after the patch.
>
Agreed -- the original comment still describes the work-array
and tree-walker setup that follows, which the patch does not
touch. Restored it in place and moved the new ISO citation
comment to sit directly above the RPR rejection foreach so
each block is documented next to the code it explains.
> ERRCODE_FEATURE_NOT_SUPPORTED should be ERRCODE_SYNTAX_ERROR instead?
> IMO ERRCODE_FEATURE_NOT_SUPPORTED is used when the feature is defined
> by the standard but PostgreSQL just has not implemented yet. In this
> case the standard disllow RPR in recursive CTE.
Right, the standard explicitly prohibits this combination
rather than leaving it unimplemented. Switched to
ERRCODE_SYNTAX_ERROR. The .out files reference only the
ERROR message so the regress expected output is unchanged.
Thanks,
Henson
From cda37c3c806c8ee99e7e2060bfab5b4105b728ad Mon Sep 17 00:00:00 2001
From: Henson Choi <[email protected]>
Date: Sun, 10 May 2026 13:51:45 +0900
Subject: [PATCH 12/15] Add rpr_integration B7 cases for RPR in recursive query
Replace the prior B7 test (which asserted that an RPR window works
in the base leg of a recursive CTE) with two cases the recursive-RPR
prohibition needs to cover: WITH RECURSIVE with RPR in the base leg,
and CREATE RECURSIVE VIEW with an RPR window. Cite ISO/IEC 19075-5
6.17.5 (R020) and 4.18.5 (R010), and the formal rule in ISO/IEC
9075-2:2016 7.17 Syntax Rule 3)e)f), and drop the deferred XXX
comment that left this case open to community input.
Expected output still matches the current (pre-rejection) behavior;
a follow-up patch adds the rejection in parse_cte.c and flips both
queries to ERROR.
---
src/test/regress/expected/rpr_integration.out | 71 ++++++-------------
src/test/regress/sql/rpr_integration.sql | 47 ++++++------
2 files changed, 43 insertions(+), 75 deletions(-)
diff --git a/src/test/regress/expected/rpr_integration.out
b/src/test/regress/expected/rpr_integration.out
index 7cbeed3347e..0b05a826a27 100644
--- a/src/test/regress/expected/rpr_integration.out
+++ b/src/test/regress/expected/rpr_integration.out
@@ -1269,54 +1269,18 @@ ORDER BY o.id, r.id;
-- ============================================================
-- B7. RPR + Recursive CTE
-- ============================================================
--- Verify that an RPR window can appear inside the non-recursive
--- (base) leg of a recursive CTE. The plan must show the RPR
--- WindowAgg sitting under the Recursive Union as the base-leg
--- child, with the WorkTable Scan feeding the recursive leg above
--- it. This confirms that RPR output can seed a recursive CTE
--- (window functions cannot appear in the recursive leg itself, a
--- PostgreSQL restriction, so this is the natural place to exercise
--- "RPR under Recursive Union").
---
--- XXX: Whether this case falls under the ISO/IEC 19075-5 6.17.5 /
--- 4.18.5 prohibition is not something I can judge. If this case
--- is not prohibited, the open question is whether a query that
--- does trigger the prohibition can be constructed at all.
--- Whether to prohibit this case is left to the community.
--- Plan: Recursive Union with the RPR WindowAgg on the base leg and
--- the WorkTable Scan on the recursive leg.
-EXPLAIN (COSTS OFF)
-WITH RECURSIVE seq AS (
- SELECT id, val, count(*) OVER w AS cnt
- FROM rpr_integ
- WINDOW w AS (ORDER BY id
- ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
- PATTERN (A B+)
- DEFINE B AS val > PREV(val))
- UNION ALL
- SELECT id + 100, val, cnt FROM seq WHERE id < 3
-)
-SELECT id, val, cnt FROM seq ORDER BY id;
- QUERY PLAN
--------------------------------------------------------------------------------------------------------
- Sort
- Sort Key: seq.id
- CTE seq
- -> Recursive Union
- -> WindowAgg
- Window: w AS (ORDER BY rpr_integ.id ROWS BETWEEN CURRENT ROW
AND UNBOUNDED FOLLOWING)
- Pattern: a b+
- Nav Mark Lookback: 1
- -> Sort
- Sort Key: rpr_integ.id
- -> Seq Scan on rpr_integ
- -> WorkTable Scan on seq seq_1
- Filter: (id < 3)
- -> CTE Scan on seq
-(14 rows)
-
--- Result: the base leg contributes the RPR match counts; the
--- recursive leg propagates those counts with shifted ids.
+-- Verify that RPR is rejected inside a recursive query.
+-- ISO/IEC 19075-5 6.17.5 (R020) and 4.18.5 (R010) cite CREATE
+-- RECURSIVE VIEW examples and state that "row pattern matching
+-- is prohibited in recursive queries". The formal rule lives in
+-- ISO/IEC 9075-2:2016 7.17 Syntax Rule 3)f): a potentially
+-- recursive <with list element> shall not contain a <row pattern
+-- measures> or <row pattern common syntax>. Per 3)e), every
+-- <with list element> under WITH RECURSIVE is "potentially
+-- recursive", so the rejection covers the base (non-recursive)
+-- leg too, not just the self-referencing leg.
+-- WITH RECURSIVE: RPR in the base leg is rejected even though the
+-- base leg never references the recursive CTE name.
WITH RECURSIVE seq AS (
SELECT id, val, count(*) OVER w AS cnt
FROM rpr_integ
@@ -1344,6 +1308,17 @@ SELECT id, val, cnt FROM seq ORDER BY id;
102 | 20 | 0
(12 rows)
+-- CREATE RECURSIVE VIEW: rewritten by makeRecursiveViewSelect()
+-- into WITH RECURSIVE, so the same rejection applies. This is
+-- the form ISO/IEC 19075-5 6.17.5 cites verbatim.
+CREATE RECURSIVE VIEW rpr_recv(id, val, cnt) AS
+ SELECT id, val, count(*) OVER w
+ FROM rpr_integ
+ WINDOW w AS (ORDER BY id
+ ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
+ PATTERN (A B+)
+ DEFINE B AS val > PREV(val));
+DROP VIEW rpr_recv;
-- ============================================================
-- B8. RPR + Incremental sort
-- ============================================================
diff --git a/src/test/regress/sql/rpr_integration.sql
b/src/test/regress/sql/rpr_integration.sql
index f4267c74645..bc8f4712bcb 100644
--- a/src/test/regress/sql/rpr_integration.sql
+++ b/src/test/regress/sql/rpr_integration.sql
@@ -783,24 +783,19 @@ ORDER BY o.id, r.id;
-- ============================================================
-- B7. RPR + Recursive CTE
-- ============================================================
--- Verify that an RPR window can appear inside the non-recursive
--- (base) leg of a recursive CTE. The plan must show the RPR
--- WindowAgg sitting under the Recursive Union as the base-leg
--- child, with the WorkTable Scan feeding the recursive leg above
--- it. This confirms that RPR output can seed a recursive CTE
--- (window functions cannot appear in the recursive leg itself, a
--- PostgreSQL restriction, so this is the natural place to exercise
--- "RPR under Recursive Union").
---
--- XXX: Whether this case falls under the ISO/IEC 19075-5 6.17.5 /
--- 4.18.5 prohibition is not something I can judge. If this case
--- is not prohibited, the open question is whether a query that
--- does trigger the prohibition can be constructed at all.
--- Whether to prohibit this case is left to the community.
-
--- Plan: Recursive Union with the RPR WindowAgg on the base leg and
--- the WorkTable Scan on the recursive leg.
-EXPLAIN (COSTS OFF)
+-- Verify that RPR is rejected inside a recursive query.
+-- ISO/IEC 19075-5 6.17.5 (R020) and 4.18.5 (R010) cite CREATE
+-- RECURSIVE VIEW examples and state that "row pattern matching
+-- is prohibited in recursive queries". The formal rule lives in
+-- ISO/IEC 9075-2:2016 7.17 Syntax Rule 3)f): a potentially
+-- recursive <with list element> shall not contain a <row pattern
+-- measures> or <row pattern common syntax>. Per 3)e), every
+-- <with list element> under WITH RECURSIVE is "potentially
+-- recursive", so the rejection covers the base (non-recursive)
+-- leg too, not just the self-referencing leg.
+
+-- WITH RECURSIVE: RPR in the base leg is rejected even though the
+-- base leg never references the recursive CTE name.
WITH RECURSIVE seq AS (
SELECT id, val, count(*) OVER w AS cnt
FROM rpr_integ
@@ -813,19 +808,17 @@ WITH RECURSIVE seq AS (
)
SELECT id, val, cnt FROM seq ORDER BY id;
--- Result: the base leg contributes the RPR match counts; the
--- recursive leg propagates those counts with shifted ids.
-WITH RECURSIVE seq AS (
- SELECT id, val, count(*) OVER w AS cnt
+-- CREATE RECURSIVE VIEW: rewritten by makeRecursiveViewSelect()
+-- into WITH RECURSIVE, so the same rejection applies. This is
+-- the form ISO/IEC 19075-5 6.17.5 cites verbatim.
+CREATE RECURSIVE VIEW rpr_recv(id, val, cnt) AS
+ SELECT id, val, count(*) OVER w
FROM rpr_integ
WINDOW w AS (ORDER BY id
ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
PATTERN (A B+)
- DEFINE B AS val > PREV(val))
- UNION ALL
- SELECT id + 100, val, cnt FROM seq WHERE id < 3
-)
-SELECT id, val, cnt FROM seq ORDER BY id;
+ DEFINE B AS val > PREV(val));
+DROP VIEW rpr_recv;
-- ============================================================
-- B8. RPR + Incremental sort
--
2.50.1 (Apple Git-155)
From c837d254bf13dcc85e07530a30210fda8b8ea27f Mon Sep 17 00:00:00 2001
From: Henson Choi <[email protected]>
Date: Sun, 10 May 2026 14:42:09 +0900
Subject: [PATCH 13/15] Reject row pattern recognition in recursive queries
Per ISO/IEC 9075-2:2016 7.17 Syntax Rule 3)e)f), every <with list
element> in a WITH RECURSIVE clause is "potentially recursive" and
shall not contain a <row pattern common syntax>. ISO/IEC 19075-5
6.17.5 (R020) and 4.18.5 (R010) restate the prohibition for CREATE
RECURSIVE VIEW, which makeRecursiveViewSelect() rewrites to WITH
RECURSIVE so the same path catches both forms.
The rejection runs in transformWithClause() against the raw parse
tree, before per-CTE analysis, and reports the PATTERN keyword
position via a new RPCommonSyntax.location field captured in
gram.y. Flips both rpr_integration B7 cases (added in the
preceding commit) from result rows to the new error.
---
src/backend/parser/gram.y | 1 +
src/backend/parser/parse_cte.c | 57 +++++++++++++++++++
src/include/nodes/parsenodes.h | 1 +
src/test/regress/expected/rpr_integration.out | 23 ++------
src/test/regress/sql/rpr_integration.sql | 1 -
src/tools/pgindent/typedefs.list | 1 +
6 files changed, 66 insertions(+), 18 deletions(-)
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index aa587e6aced..a2fafb717cd 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -17585,6 +17585,7 @@ opt_row_pattern_skip_to opt_row_pattern_initial_or_seek
n->initial = $2;
n->rpPattern = (RPRPatternNode *) $5;
n->rpDefs = $8;
+ n->location = @3;
$$ = (Node *) n;
}
| /*EMPTY*/ { $$ = NULL; }
diff --git a/src/backend/parser/parse_cte.c b/src/backend/parser/parse_cte.c
index ccde199319a..0974b43d028 100644
--- a/src/backend/parser/parse_cte.c
+++ b/src/backend/parser/parse_cte.c
@@ -96,6 +96,14 @@ static void checkWellFormedRecursion(CteState *cstate);
static bool checkWellFormedRecursionWalker(Node *node, CteState *cstate);
static void checkWellFormedSelectStmt(SelectStmt *stmt, CteState *cstate);
+/* Recursive-WITH RPR rejection */
+typedef struct
+{
+ ParseLoc location; /* location of first RPR
window, or -1 */
+} ContainRPRContext;
+
+static bool contain_rpr_walker(Node *node, void *context);
+
/*
* transformWithClause -
@@ -164,6 +172,29 @@ transformWithClause(ParseState *pstate, WithClause
*withClause)
CteState cstate;
int i;
+ /*
+ * Per ISO/IEC 9075-2:2016 7.17 Syntax Rule 3)e)f), every <with
list
+ * element> in a WITH RECURSIVE clause is "potentially
recursive" and
+ * shall not contain a <row pattern common syntax>.
(PostgreSQL does
+ * not implement <row pattern measures>, so only the common
syntax
+ * needs to be checked.) ISO/IEC 19075-5 6.17.5 (R020) and
4.18.5
+ * (R010) restate the prohibition for CREATE RECURSIVE VIEW,
which is
+ * rewritten to WITH RECURSIVE by makeRecursiveViewSelect() and
so
+ * flows through here as well.
+ */
+ foreach(lc, withClause->ctes)
+ {
+ CommonTableExpr *cte = (CommonTableExpr *) lfirst(lc);
+ ContainRPRContext ctx;
+
+ ctx.location = -1;
+ if (contain_rpr_walker(cte->ctequery, &ctx))
+ ereport(ERROR,
+ errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("cannot use row pattern
recognition in a recursive query"),
+ parser_errposition(pstate,
ctx.location));
+ }
+
cstate.pstate = pstate;
cstate.numitems = list_length(withClause->ctes);
cstate.items = (CteItem *) palloc0(cstate.numitems *
sizeof(CteItem));
@@ -1268,3 +1299,29 @@ checkWellFormedSelectStmt(SelectStmt *stmt, CteState
*cstate)
}
}
}
+
+
+/*
+ * contain_rpr_walker
+ * Returns true if the raw parse tree contains any <row pattern common
+ * syntax> -- i.e., any WindowDef with PATTERN/DEFINE attached. Used
+ * by transformWithClause() to enforce ISO/IEC 9075-2:2016 7.17 SR 3)f)
+ * on WITH RECURSIVE elements.
+ */
+static bool
+contain_rpr_walker(Node *node, void *context)
+{
+ if (node == NULL)
+ return false;
+ if (IsA(node, WindowDef))
+ {
+ WindowDef *wd = (WindowDef *) node;
+
+ if (wd->rpCommonSyntax != NULL)
+ {
+ ((ContainRPRContext *) context)->location =
wd->rpCommonSyntax->location;
+ return true;
+ }
+ }
+ return raw_expression_tree_walker(node, contain_rpr_walker, context);
+}
diff --git a/src/include/nodes/parsenodes.h b/src/include/nodes/parsenodes.h
index adefb1d5bad..5200182aa46 100644
--- a/src/include/nodes/parsenodes.h
+++ b/src/include/nodes/parsenodes.h
@@ -646,6 +646,7 @@ typedef struct RPCommonSyntax
RPRPatternNode *rpPattern; /* PATTERN clause AST */
List *rpDefs; /* row pattern definitions
clause (list of
* ResTarget) */
+ ParseLoc location; /* PATTERN keyword location, or
-1 */
} RPCommonSyntax;
/*
diff --git a/src/test/regress/expected/rpr_integration.out
b/src/test/regress/expected/rpr_integration.out
index 0b05a826a27..b598ef95776 100644
--- a/src/test/regress/expected/rpr_integration.out
+++ b/src/test/regress/expected/rpr_integration.out
@@ -1292,22 +1292,9 @@ WITH RECURSIVE seq AS (
SELECT id + 100, val, cnt FROM seq WHERE id < 3
)
SELECT id, val, cnt FROM seq ORDER BY id;
- id | val | cnt
------+-----+-----
- 1 | 10 | 2
- 2 | 20 | 0
- 3 | 15 | 2
- 4 | 25 | 0
- 5 | 5 | 3
- 6 | 30 | 0
- 7 | 35 | 0
- 8 | 20 | 3
- 9 | 40 | 0
- 10 | 45 | 0
- 101 | 10 | 2
- 102 | 20 | 0
-(12 rows)
-
+ERROR: cannot use row pattern recognition in a recursive query
+LINE 6: PATTERN (A B+)
+ ^
-- CREATE RECURSIVE VIEW: rewritten by makeRecursiveViewSelect()
-- into WITH RECURSIVE, so the same rejection applies. This is
-- the form ISO/IEC 19075-5 6.17.5 cites verbatim.
@@ -1318,7 +1305,9 @@ CREATE RECURSIVE VIEW rpr_recv(id, val, cnt) AS
ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
PATTERN (A B+)
DEFINE B AS val > PREV(val));
-DROP VIEW rpr_recv;
+ERROR: cannot use row pattern recognition in a recursive query
+LINE 6: PATTERN (A B+)
+ ^
-- ============================================================
-- B8. RPR + Incremental sort
-- ============================================================
diff --git a/src/test/regress/sql/rpr_integration.sql
b/src/test/regress/sql/rpr_integration.sql
index bc8f4712bcb..5f3853becba 100644
--- a/src/test/regress/sql/rpr_integration.sql
+++ b/src/test/regress/sql/rpr_integration.sql
@@ -818,7 +818,6 @@ CREATE RECURSIVE VIEW rpr_recv(id, val, cnt) AS
ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
PATTERN (A B+)
DEFINE B AS val > PREV(val));
-DROP VIEW rpr_recv;
-- ============================================================
-- B8. RPR + Incremental sort
diff --git a/src/tools/pgindent/typedefs.list b/src/tools/pgindent/typedefs.list
index d23b392800e..da10b4ac546 100644
--- a/src/tools/pgindent/typedefs.list
+++ b/src/tools/pgindent/typedefs.list
@@ -534,6 +534,7 @@ Constraint
ConstraintCategory
ConstraintInfo
ConstraintsSetStmt
+ContainRPRContext
ControlData
ControlFileData
ConvInfo
--
2.50.1 (Apple Git-155)
From fe8edf9e1a79141ad63e731101bb8332d8158d72 Mon Sep 17 00:00:00 2001
From: Henson Choi <[email protected]>
Date: Tue, 12 May 2026 15:38:03 +0900
Subject: [PATCH 14/15] Enhance README.rpr per Tatsuo Ishii's review
Apply Tatsuo Ishii's enhancement patch on top of v47:
- Make "target audience" and "scope" more descriptive,
pointing readers to the SQL standard (and Oracle/Trino
manuals as alternatives)
- Spell out NFA and AST on first use
- Cross-reference the absorbability sections from the
RPR_ELEM_ABSORBABLE_BRANCH flag description
- List additional WindowAggState fields in V-3
(nfaVisitedNWords, defineMatchStartDependent,
nfaLastProcessedRow)
- State the window framing rules that apply with RPR
- Add a References section (SQL standards)
---
src/backend/executor/README.rpr | 49 ++++++++++++++++++++++++---------
1 file changed, 36 insertions(+), 13 deletions(-)
diff --git a/src/backend/executor/README.rpr b/src/backend/executor/README.rpr
index e64efe0c7fc..6c2bddab455 100644
--- a/src/backend/executor/README.rpr
+++ b/src/backend/executor/README.rpr
@@ -2,11 +2,15 @@
PostgreSQL Row Pattern Recognition: Flat-Array Stream NFA Guide
============================================================================
- Target audience: Developers with a basic understanding of the PostgreSQL
- executor and planner architecture
+ This README's target audience is developers with a basic
+ understanding of the PostgreSQL executor and planner architecture.
+ Also it would be better for them to understand the specification of
+ the row pattern recognition in the SQL standard [1][2]. If you do
+ not have access to the SQL standard, Oracle's manual or Trino's
+ manual can be alternatives for them.
- Scope: The entire process from PATTERN/DEFINE clause parsing to NFA
- runtime execution
+ This README's scope is the entire process from PATTERN/DEFINE clause
+ parsing to NFA runtime execution.
Related code:
- src/backend/parser/parse_rpr.c (parser phase)
@@ -23,10 +27,11 @@
What is a Flat-Array Stream NFA?
- The NFA in this implementation is not a traditional state-transition graph
- but a flat array of fixed-size 16-byte elements. At runtime, it processes
- the row stream in a forward-only manner, expanding epsilon transitions
- eagerly without backtracking.
+ The NFA (Nondeterministic Finite Automaton) in this implementation
+ is not a traditional state-transition graph but a flat array of
+ fixed-size 16-byte elements. At runtime, it processes the row stream
+ in a forward-only manner, expanding epsilon transitions eagerly
+ without backtracking.
- Flat-Array: Pattern compiled into a flat array,
not a graph (Chapter IV)
@@ -132,14 +137,14 @@ following:
(3) DEFINE clause transformation (transformDefineClause)
-III-2. PATTERN AST
+III-2. PATTERN AST (Abstract Syntax Tree)
The parser transforms the PATTERN clause into an RPRPatternNode tree.
Each node has one of the following four types:
RPR_PATTERN_VAR Variable reference. Name stored in varName field.
RPR_PATTERN_SEQ Concatenation. Children node list in children.
- RPR_PATTERN_ALT Alternation. Branch node list in children.
+ RPR_PATTERN_ALT Alternation (or). Branch node list in children.
RPR_PATTERN_GROUP Group (parentheses). Body node list in children.
All nodes have min/max fields to express quantifiers:
@@ -270,9 +275,11 @@ Element flags (1 byte, bitmask):
matches. (IV-4b)
0x04 RPR_ELEM_ABSORBABLE_BRANCH (VAR, BEGIN, END, ALT)
- Element lies within an absorbable region. Used at runtime
- to track whether the current NFA state is in an absorbable
- context.
+ Element lies within an absorbable region. Used at runtime to
+ track whether the current NFA state is in an absorbable
+ context. See "IV-5. Absorbability Analysis" and
+ "VIII-2. Solution: Context Absorption" for more details about
+ absorption.
0x08 RPR_ELEM_ABSORBABLE (VAR, END)
Absorption judgment point. Where to compare consecutive
@@ -514,7 +521,10 @@ V-3. RPR Fields of WindowAggState
nfaStateFree Reuse pool for states
nfaVarMatched Per-row cache: varMatched[varId]
nfaVisitedElems Bitmap for cycle detection
+ nfaVisitedNWords Number of bitmapwords in nfaVisitedElems
nfaStateSize Precomputed size of RPRNFAState
+ defineMatchStartDependent DEFINE vars needing per-context evaluation
(match_start-dependent)
+ nfaLastProcessedRow Last row processed by NFA (-1 = none)
Memory management:
@@ -1053,6 +1063,10 @@ X-3. INITIAL vs SEEK
X-4. Bounded Frame Handling
+ With RPR, the frame mode is always ROWS and the frame start must be
+ CURRENT ROW. The frame end can be either UNBOUNDED FOLLOWING or n
+ FOLLOWING.
+
When the frame is bounded (e.g., ROWS BETWEEN CURRENT ROW AND 5
FOLLOWING), ExecRPRProcessRow receives hasLimitedFrame=true and
frameOffset indicating the upper bound. Before the match phase,
@@ -1579,6 +1593,15 @@ C-7. PATTERN ((A+ B | C*)+ D) -- Per-branch absorption
in ALT
nullable.
BEGIN and ALT get ABSORBABLE_BRANCH (on the path to absorbable elements).
+
+References:
+
+[1] ISO/IEC 19075-5 Information technology - Guidance for the use of
+ database language SQL - Part 5: Row pattern recognition
+
+[2] ISO/IEC 9075-2 Information technology - Database languages - SQL -
+ Part 2: Foundation (SQL/Foundation)
+
============================================================================
End of document
============================================================================
--
2.50.1 (Apple Git-155)
From ad5f8dc3b587b2aed17954b5bfcdea2a4c94c288 Mon Sep 17 00:00:00 2001
From: Henson Choi <[email protected]>
Date: Tue, 12 May 2026 15:43:49 +0900
Subject: [PATCH 15/15] Round out README.rpr WindowAggState field coverage
Follow-up to the previous commit applying Tatsuo Ishii's
review. That commit added three WindowAggState fields to
V-3 but left a few related entries out, and Appendix B's
diagram still showed the pre-review field list.
- Add nfaVisitedMinWord and nfaVisitedMaxWord to V-3
- Note that EXPLAIN ANALYZE instrumentation counters are
omitted from V-3 (see execnodes.h)
- Mirror the V-3 additions in the Appendix B diagram
---
src/backend/executor/README.rpr | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/src/backend/executor/README.rpr b/src/backend/executor/README.rpr
index 6c2bddab455..6ff7f33e62e 100644
--- a/src/backend/executor/README.rpr
+++ b/src/backend/executor/README.rpr
@@ -522,10 +522,15 @@ V-3. RPR Fields of WindowAggState
nfaVarMatched Per-row cache: varMatched[varId]
nfaVisitedElems Bitmap for cycle detection
nfaVisitedNWords Number of bitmapwords in nfaVisitedElems
+ nfaVisitedMinWord Lowest bitmapword index touched since last
reset
+ nfaVisitedMaxWord Highest bitmapword index touched since last
reset
nfaStateSize Precomputed size of RPRNFAState
defineMatchStartDependent DEFINE vars needing per-context evaluation
(match_start-dependent)
nfaLastProcessedRow Last row processed by NFA (-1 = none)
+ EXPLAIN ANALYZE instrumentation counters are omitted here; see
+ execnodes.h for the full list.
+
Memory management:
States and contexts are managed through their own free lists.
@@ -1480,7 +1485,13 @@ Appendix B. Data Structure Relationship Diagram
|--- defineVariableList: List<String> (variable names, DEFINE order)
|--- defineClauseList: List<ExprState>
|--- nfaVarMatched: bool[] (per-row cache)
+ |--- defineMatchStartDependent: Bitmapset* (match_start-dependent
+ | DEFINE vars; see VI-4)
|--- nfaVisitedElems: bitmapword* (cycle detection)
+ |--- nfaVisitedNWords: int (size of nfaVisitedElems)
+ |--- nfaVisitedMinWord / nfaVisitedMaxWord: int16
+ | (touched-word range for fast reset)
+ |--- nfaLastProcessedRow: int64 (-1 = none)
|--- nfaStateSize: Size (pre-calculated RPRNFAState allocation size)
|--- nfaContext <-> nfaContextTail (doubly-linked list)
| +--- RPRNFAContext
--
2.50.1 (Apple Git-155)
