Re: Row pattern recognition - Mailing list pgsql-hackers

On Mon, Sep 7, 2026 at 6:13 PM Henson Choi <assam258@gmail.com> wrote:
>
> Hi hackers,
>
> This is the increment on top of v51.  It is 27 patches, named
> nocfbot-XXXX-*.txt as before.
>
>   2020 Bring README.rpr level with the code it describes
>        [comments]
>        Read from the code back to the document, the README was
>        wrong in eighteen places and silent about more:
>
>        - the wrong ones had mostly outlived the code they
>          described
>        - what the feature asks of the planner had never been
>          written down, nor anything about the two printers that
>          display a pattern; those are two new chapters, appended
>          so no existing number moves
>        - eight more sections fill gaps inside the existing ones
>

IMHO, src/backend/executor/README.rpr should focus on something that's not easy
to understand for users with some knowledge of the PostgreSQL codebase:
the matching machinery in execRPR.c and nodeWindowAgg.c, and
absorption optimization in particular.

+IV-6. Plan Serialization of RPRPattern
+
+RPRPattern carries two variable-length arrays, so the generated node support
+cannot handle it: plannodes.h marks it pg_node_attr(custom_copy_equal,
+custom_read_write, no_equal, no_query_jumble) and the three routines are
+written by hand -- _copyRPRPattern() in copyfuncs.c, _outRPRPattern() in

This process is quite common, since other nodes do something similar. BTW,
"serialization" is not the usual word here; we generally use "deparse"
for ruleutils.

+IV-2a. Compilation Limits
+
+Phase 2 is also where a pattern too large for the element array is
+rejected.  scanRPRPattern() raises two errors, both
+ERRCODE_PROGRAM_LIMIT_EXCEEDED:
+
+  "pattern nesting too deep"
+    A group or alternation nested RPR_DEPTH_MAX levels or deeper.  The
+    test is made on entry to each node, before its children raise the
+    counter, so the one-byte RPRDepth can never wrap.  maxDepth is the
+    deepest depth plus one (it is the length of a state's counts[]), so
+    the deepest nesting a pattern may carry is RPR_DEPTH_MAX - 1.
+
This part doesn't need mentioning; it should be fine even if omitted
from the doc, i think.

+XIII-5. Where Volatility Is Rejected
+
+A DEFINE expression may not contain a volatile function, but volatility is
+not tested during parse analysis.

Common routine; no need to mention in README.rpr

+XIV-3. Pattern Variable Quoting
+
+A pattern variable is printed by quote_pattern_variable() (ruleutils.c),
+which is quote_identifier() plus one extra case: the name permute is qu
This part also doesn't need to be included.

Common routine; no need to mention in README.rpr.

+III-6. What a DEFINE Expression May Not Contain
+A DEFINE expression may not contain a subquery, an aggregate, a window
+ function or a GROUPING expression.

+ III-7. Query Jumbling
+A DEFINE clause is a list of TargetEntry whose resname carries the variable
+being defined, and TargetEntry.resname is query_jumble_ignore everywhere
+else in the tree.  Left at that, "DEFINE A AS p > 50, B AS p < 50" and
+"DEFINE B AS p > 50, A AS p < 50" would jumble alike and share one

Common routine; it doesn't need mentioning in README.rpr.

---
The above illustrates the purpose. However, many of these sections do
not need to remain in README.rpr.
Many common routines already contain extensive comments, regression
tests include comments, and error messages provide
Also some of the text seems AI-generated and less readable.

Therefore, I think many of the sections in README.rpr can be removed.



--
jian
https://www.enterprisedb.com/