> 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
