Re: Row pattern recognition

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: assam258(at)gmail(dot)com
Cc: jian(dot)universality(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, zsolt(dot)parragi(at)percona(dot)com, sjjang112233(at)gmail(dot)com, vik(at)postgresfriends(dot)org, 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-06-29 09:37:30
Message-ID: 20260629.183730.1799088184925453299.ishii@postgresql.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Hi hackers,
>
> This is v50, folding in the outstanding review. From my side there are no
> known issues left, so I think it makes a good starting point for the kind of
> thorough public review the feature should get before commit.

Thanks for the incremental patches. I am going to publish v50 patch series.
Here are some commnets to the v50-* patches.

> First, two cleanups splitting changes unrelated to RPR out of the feature
> patch:
>
> v50-0001 Remove blank-line changes unrelated to row pattern recognition
> v50-0002 Remove unnecessary includes from the row pattern recognition
> patch

0001 and 0002 look good to me.

> The fixes (v50-0003..0005, all behavior-changing):
>
> v50-0003 Recognize row pattern navigation operations by name in DEFINE

diff --git a/src/backend/parser/parse_func.c b/src/backend/parser/parse_func.c
index 1f6c8fa4fb2..f3b37aa992c 100644
--- a/src/backend/parser/parse_func.c
+++ b/src/backend/parser/parse_func.c

@@ -2111,6 +2080,151 @@ FuncNameAsType(List *funcname)

+ if (fn->func_variadic)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("cannot use VARIADIC with row pattern navigation function %s",
+ navname),
+ parser_errposition(pstate, location)));
+ if (argnames != NIL)
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("row pattern navigation operations cannot use named arguments"),
+ parser_errposition(pstate, location)));

Shouldn't the error code for the named arguments case be
ERRCODE_SYNTAX_ERROR? As far as I know the SQL standard does not allow
to use named arguments with row pattern navigation operations. So it's
not a required feature.

Also errmsg is different from surroundings. Probably "cannot use named
arguments with row pattern navigation function %s" is better?

diff --git a/src/backend/parser/parse_rpr.c b/src/backend/parser/parse_rpr.c
index 3eaea2be750..8ed01bb8f28 100644
--- a/src/backend/parser/parse_rpr.c
+++ b/src/backend/parser/parse_rpr.c
@@ -472,6 +472,7 @@ transformDefineClause(ParseState *pstate, WindowClause *wc, WindowDef *windef,
* * PREV/NEXT wrapping FIRST/LAST flattens to a compound kind
* * Other nestings are rejected (FIRST(PREV()), PREV(PREV()), ...)
* * offset_arg / compound_offset_arg must not contain column refs
+ * or nested navigation operations

Needs '*' in front of "or nested....".

> v50-0004 Use a dedicated ExprContext for RPR DEFINE clause evaluation

Looks good to me.

Will continue reviewes tomorrow.

Regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuro Yamada 2026-06-29 10:02:29 RE: Add enable_groupagg GUC parameter to control GroupAggregate usage
Previous Message John Naylor 2026-06-29 09:35:39 Re: vectorized CRC on ARM64