From: Tom Lane <tgl@sss.pgh.pa.us>
To: Maaz Syed Adeeb <maaz.adeeb@gmail.com>
cc: pgsql-bugs@lists.postgresql.org, matthew.ripley28@gmail.com
Subject: Re: CREATE INDEX with an expression in an INCLUDE column fails with
 XX000 "unrecognized node type" instead of 0A000 on master
In-reply-to: 
 <CAG+FJqOxYj=sVyHcys64h9DbvzP6EUPGHJ7oKj-PW=Qp5Ebk_g@mail.gmail.com>
References: 
 <CAG+FJqOxYj=sVyHcys64h9DbvzP6EUPGHJ7oKj-PW=Qp5Ebk_g@mail.gmail.com>
Comments: In-reply-to Maaz Syed Adeeb <maaz.adeeb@gmail.com>
	message dated "Wed, 15 Jul 2026 06:05:06 -0700"
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <3574683.1784140106.0@sss.pgh.pa.us>
Date: Wed, 15 Jul 2026 14:29:04 -0400
Message-ID: <3574719.1784140144@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3574719.1784140144%40sss.pgh.pa.us>
Precedence: bulk

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3574683.1784140106.1@sss.pgh.pa.us>

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


------- =_aaaaaaaaaa0
Content-Type: text/x-diff; name="wip-fix-index-included-expressions.patch";
	charset="us-ascii"
Content-ID: <3574683.1784140106.2@sss.pgh.pa.us>
Content-Description: wip-fix-index-included-expressions.patch
Content-Transfer-Encoding: quoted-printable

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, cons=
t 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 =3D (IndexElem *) lfirst(l);
+
+		if (ielem->expr)
+		{
+			/* Do parse transformation of the expression */
+			ielem->expr =3D 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.)

------- =_aaaaaaaaaa0--