| From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
|---|---|
| To: | assam258(at)gmail(dot)com |
| Cc: | shinsj4653(at)gmail(dot)com, jian(dot)universality(at)gmail(dot)com, vik(at)postgresfriends(dot)org, pgsql-hackers(at)postgresql(dot)org, zsolt(dot)parragi(at)percona(dot)com, sjjang112233(at)gmail(dot)com, er(at)xs4all(dot)nl, jacob(dot)champion(at)enterprisedb(dot)com, david(dot)g(dot)johnston(at)gmail(dot)com, peter(at)eisentraut(dot)org, li(dot)evan(dot)chao(at)gmail(dot)com |
| Subject: | Re: Row pattern recognition |
| Date: | 2026-07-21 00:38:48 |
| Message-ID: | 20260721.093848.828146987919846740.ishii@postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Henson,
> 2XXX -- awaiting review from Tatsuo
I have finished reviewing 2015-2026 patches.
> 2015 Tidy up the row pattern unbounded-quantifier sentinel
> (= v50-0014)
> Revised per your 07-19 comment. The macro is no longer a local
> copy in gram.y: RPR_QUANTITY_INF is now defined once in
> nodes/parsenodes.h, next to RPRPatternNode whose max field
> stores it, and gram.y and optimizer/rpr.h use that one
> definition. On the placement -- you suggested primnodes.h; I
> put it in parsenodes.h because that is where RPRPatternNode
> lives, and parsenodes.h includes primnodes.h, so every stage
> that saw the macro before still does. Happy to move it to
> primnodes.h if you would rather keep it there.
Looks Ok. parsenodes.h is fine for me.
> 2016 Simplify row pattern compilation by passing the
> WindowClause (= v50-0015)
> buildRPRPattern() took rpPattern, rpSkipTo, frameOptions, and a
> pre-built defineVariableList as separate arguments. Pass the
> WindowClause directly instead: it carries all of these, and
> buildRPRPattern can walk wc->defineClause itself to collect the DEFINE
> variable names. This removes the intermediate List that
I am not sure if replacing those arguments with WindowClause is a good
idea. This would simplify buildRPRPattern() but at the same time it
will make it hard to call the function from R010 implementation
because MATCH_RECOGNIZE node surely will not have WindowClause node. I
know R010 is out of scope of our work but thinking about re-usability is
courtesy for the future implementer of R010.
> 2017 Reword the row pattern variable-limit error (= v50-0016)
OK.
> 2018 Reformat row pattern regression tests for
> readability (= v50-0017)
Ok.
> 2019 Add row pattern recognition coverage tests and tidy
> unreachable code (= v50-0018)
I think we should not include following patch in our patch set. That
has nothing to do with RPR.
--- a/src/backend/executor/nodeWindowAgg.c
+++ b/src/backend/executor/nodeWindowAgg.c
@@ -4937,12 +4937,11 @@ WinCheckAndInitializeNullTreatment(WindowObject winobj,
{
const char *funcname = get_func_name(fcinfo->flinfo->fn_oid);
- if (!funcname)
- elog(ERROR, "could not get function name");
+ /* the executing function's name always resolves; stay safe regardless */
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("function %s does not allow RESPECT/IGNORE NULLS",
- funcname)));
+ funcname ? funcname : "?")));
}
else if (winobj->ignore_nulls == PARSER_IGNORE_NULLS)
winobj->ignore_nulls = IGNORE_NULLS;
> 2020 Free RPR NFA states with pfree() under
> USE_VALGRIND (= v50-0019)
Ok.
> 2021 Clarify row pattern recognition comments on "step" and
> no_equal (= v50-0020)
Ok.
> 2022 Extract the reduced-frame guard into ensure_reduced_frame()
Ok.
> 2023 Clean up row pattern recognition internals
> - Pass currentPos into nfa_match so the current row index is visible in a
> debugger; it is the only NFA helper that otherwise lacks it. The
> parameter has no runtime consumer yet.
There's no instance in PostgreSQL code which uses
pg_attribute_unused() with function arguments for debugging
purpose. Can you clarify why this is necessary (except just for
debugging convenience)?
> 2024 Improve row pattern recognition comments and documentation
Ok.
> 2025 Expand row pattern recognition regression tests
Ok.
> 2026 Fix context absorption discarding matches on non-absorbable
> branches
> [behavior change -- wrong results]
Ok.
> You mentioned you would continue through 2016..2021; those, and 2022..2026,
> are unchanged from the 07-13 posting.
Regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2026-07-21 00:42:03 | Re: Fix "unexpected logical decoding status change" error; from concurrent logical decoding activation |
| Previous Message | Michael Paquier | 2026-07-20 22:41:23 | Re: Unexpected behavior after OOM errors |