Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1no5Ga-0007pm-4k for pgsql-bugs@arkaria.postgresql.org; Mon, 09 May 2022 15:25:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1no5GY-0004Xf-Qm for pgsql-bugs@arkaria.postgresql.org; Mon, 09 May 2022 15:25:42 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1no5GY-0004XW-Ia for pgsql-bugs@lists.postgresql.org; Mon, 09 May 2022 15:25:42 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1no5GW-0001Rq-8h for pgsql-bugs@lists.postgresql.org; Mon, 09 May 2022 15:25:41 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 249FPcZq3809469; Mon, 9 May 2022 11:25:38 -0400 From: Tom Lane To: Masahiko Sawada cc: krking@zju.edu.cn, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17477: A crash bug in transformValuesClause() In-reply-to: References: <17477-0af3c6ac6b0a6ae0@postgresql.org> Comments: In-reply-to Masahiko Sawada message dated "Mon, 09 May 2022 23:03:56 +0900" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <3809061.1652109907.0@sss.pgh.pa.us> Date: Mon, 09 May 2022 11:25:38 -0400 Message-ID: <3809468.1652109938@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3809061.1652109907.1@sss.pgh.pa.us> Masahiko Sawada writes: > It seems like transformValuesClause() cannot handle properly the value > clause having a relation that has an empty column. Should we raise an > error in this case? Given that we try to support zero-column relations, I'm not sure why we'd insist on disallowing zero-column VALUES. I think the problem is that the code in transformValuesClause needs to be tweaked to make that work. The attached quick hack seems to do the trick. regards, tom lane ------- =_aaaaaaaaaa0 Content-Type: text/x-diff; name="allow-zero-columns-in-VALUES.patch"; charset="us-ascii" Content-ID: <3809061.1652109907.2@sss.pgh.pa.us> Content-Description: allow-zero-columns-in-VALUES.patch Content-Transfer-Encoding: quoted-printable diff --git a/src/backend/parser/analyze.c b/src/backend/parser/analyze.c index 0144284aa3..6b54e8e46d 100644 --- a/src/backend/parser/analyze.c +++ b/src/backend/parser/analyze.c @@ -1424,7 +1424,7 @@ static Query * transformValuesClause(ParseState *pstate, SelectStmt *stmt) { Query *qry =3D makeNode(Query); - List *exprsLists; + List *exprsLists =3D NIL; List *coltypes =3D NIL; List *coltypmods =3D NIL; List *colcollations =3D NIL; @@ -1508,6 +1508,9 @@ transformValuesClause(ParseState *pstate, SelectStmt= *stmt) = /* Release sub-list's cells to save memory */ list_free(sublist); + + /* Prepare an exprsLists element for this row */ + exprsLists =3D lappend(exprsLists, NIL); } = /* @@ -1551,17 +1554,7 @@ transformValuesClause(ParseState *pstate, SelectStm= t *stmt) /* * Finally, rearrange the coerced expressions into row-organized lists. */ - exprsLists =3D NIL; - foreach(lc, colexprs[0]) - { - Node *col =3D (Node *) lfirst(lc); - List *sublist; - - sublist =3D list_make1(col); - exprsLists =3D lappend(exprsLists, sublist); - } - list_free(colexprs[0]); - for (i =3D 1; i < sublist_length; i++) + for (i =3D 0; i < sublist_length; i++) { forboth(lc, colexprs[i], lc2, exprsLists) { @@ -1569,6 +1562,7 @@ transformValuesClause(ParseState *pstate, SelectStmt= *stmt) List *sublist =3D lfirst(lc2); = sublist =3D lappend(sublist, col); + lfirst(lc2) =3D sublist; } list_free(colexprs[i]); } ------- =_aaaaaaaaaa0--