Re: Row pattern recognition - Mailing list 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