Date: Mon, 29 Jun 2026 18:37:30 +0900 (JST)
Message-Id: <20260629.183730.1799088184925453299.ishii@postgresql.org>
To: assam258@gmail.com
Cc: jian.universality@gmail.com, pgsql-hackers@postgresql.org,
 zsolt.parragi@percona.com, sjjang112233@gmail.com,
 vik@postgresfriends.org, er@xs4all.nl, jacob.champion@enterprisedb.com,
 david.g.johnston@gmail.com, peter@eisentraut.org, li.evan.chao@gmail.com
Subject: Re: Row pattern recognition
From: Tatsuo Ishii <ishii@postgresql.org>
In-Reply-To: 
 <CAAAe_zChW=nM9J18wdF2wMa2KesFO53fkbVRudkJ_bstdxzfOQ@mail.gmail.com>
References: 
 <CAAAe_zCsaf=WedELLjqLe3BV_8dWiO1DPDGA9sXj4qhe+=-XXw@mail.gmail.com>
	<20260622.215536.1729984032454200237.ishii@postgresql.org>
	<CAAAe_zChW=nM9J18wdF2wMa2KesFO53fkbVRudkJ_bstdxzfOQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20260629.183730.1799088184925453299.ishii%40postgresql.org>
Precedence: bulk

> 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