Maaz Syed Adeeb <maaz.adeeb@gmail.com> writes:
> On current master, creating an index with an expression in an INCLUDE
> (non-key) column fails with an internal error ("unrecognized node
> type", SQLSTATE XX000) instead of the user-facing
> FEATURE_NOT_SUPPORTED (0A000) "expressions are not supported in
> included columns". The statement is still correctly rejected, but with
> the wrong error class and a message.
Thanks for the report! This is evidently happening because we have
not applied parse transformation to the included columns. I think
that the most appropriate way to fix it is to start doing so, even
though the feature will be rejected later. More or less as attached
(but we ought to add a test case too).
regards, tom lane
diff --git a/src/backend/parser/parse_utilcmd.c b/src/backend/parser/parse_utilcmd.c
index 58ccc7b68f2..ccf6ee55310 100644
--- a/src/backend/parser/parse_utilcmd.c
+++ b/src/backend/parser/parse_utilcmd.c
@@ -3122,6 +3122,26 @@ transformIndexStmt(Oid relid, IndexStmt *stmt, const char *queryString)
}
}
+ /*
+ * Likewise take care of any expressions in INCLUDING. (At this writing,
+ * those will be rejected later on, but probably someday we'll wish to
+ * support them.)
+ */
+ foreach(l, stmt->indexIncludingParams)
+ {
+ IndexElem *ielem = (IndexElem *) lfirst(l);
+
+ if (ielem->expr)
+ {
+ /* Do parse transformation of the expression */
+ ielem->expr = transformExpr(pstate, ielem->expr,
+ EXPR_KIND_INDEX_EXPRESSION);
+
+ /* We have to fix its collations too */
+ assign_expr_collations(pstate, ielem->expr);
+ }
+ }
+
/*
* Check that only the base rel is mentioned. (This should be dead code
* now that add_missing_from is history.)