From 26ff8122ea01c9208b8c7c48bca330192c18d08d Mon Sep 17 00:00:00 2001 From: Henson Choi Date: Thu, 7 May 2026 21:00:48 +0900 Subject: [PATCH 09/11] 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 69148328719..58ebd7d24b8 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)