nocfbot-0009-Document-DEFINE-subquery-rejection-as-intentional.txt
text/plain
Filename: nocfbot-0009-Document-DEFINE-subquery-rejection-as-intentional.txt
Type: text/plain
Part: 5
Message:
Re: Row pattern recognition
From fc00ddd90fce1026366ff3dc9042e3edb28f1ccf Mon Sep 17 00:00:00 2001
From: Henson Choi <assam258@gmail.com>
Date: Thu, 7 May 2026 21:00:48 +0900
Subject: [PATCH 09/26] Document DEFINE subquery rejection as intentional
over-rejection
The SubLink switch in transformSubLink() rejects every subquery in
EXPR_KIND_RPR_DEFINE with no inline rationale. Add an XXX block
recording that SQL/RPR (19075-5 4.18.4 / 6.17.4; R010 /
R020) actually permits a nested subquery in DEFINE provided it
does not itself perform row pattern recognition and does not
reference an outer pattern variable, and that the blanket
rejection here subsumes both restrictions by making the subquery
itself unreachable.
Implementing the case distinction would mean walking the analyzed
subquery Query tree for nested RPR and walking it for ColumnRef
qualifiers matching any ancestor's p_rpr_pattern_vars; both are
doable with the existing infrastructure and are left as future
work, not blocked on any other feature. Comment-only change.
---
src/backend/parser/parse_expr.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/src/backend/parser/parse_expr.c b/src/backend/parser/parse_expr.c
index 4221643d9c8..10edccb8afb 100644
--- a/src/backend/parser/parse_expr.c
+++ b/src/backend/parser/parse_expr.c
@@ -1944,6 +1944,28 @@ transformSubLink(ParseState *pstate, SubLink *sublink)
case EXPR_KIND_FOR_PORTION:
err = _("cannot use subquery in FOR PORTION OF expression");
break;
+
+ /*----------
+ * XXX SQL/RPR (19075-5 4.18.4 / 6.17.4; R010 / R020)
+ * permits a subquery nested in a DEFINE expression provided
+ * that:
+ * (a) the subquery does not itself perform row pattern
+ * recognition, and
+ * (b) the subquery does not reference a row pattern variable
+ * of the outer query.
+ *
+ * We reject all subqueries here for now. Implementing the
+ * case distinction would mean walking the analyzed subquery
+ * Query tree for nested RPR window clauses to enforce (a),
+ * and walking it for ColumnRef qualifiers matching any
+ * ancestor's p_rpr_pattern_vars to enforce (b). Both checks
+ * are doable with the existing infrastructure -- they are
+ * left as future work, not blocked on any other feature.
+ * Until then this blanket rejection is intentional
+ * over-rejection, not a standard fit; it subsumes both (a)
+ * and (b) by making the subquery itself unreachable.
+ *----------
+ */
case EXPR_KIND_RPR_DEFINE:
err = _("cannot use subquery in DEFINE expression");
break;
--
2.50.1 (Apple Git-155)