Re: BUG #17480: Assertion failure in parse_relation.c

On 2022-May-10, PG Bug reporting form wrote:

> Testcase:
> ```
> CREATE TABLE v0 ( v3 INT , v2 VARCHAR , v1 INT , UNIQUE ( v1 , v3 ) ) ;
> VALUES ( - - -128 , - - - - 127 , NULL ) ;
> SELECT FROM LATERAL XMLTABLE ( ROW ( ) PASSING NULL BY VALUE COLUMNS v1
> TIMESTAMP WITHOUT TIME ZONE ARRAY ) AS DELETE ( v3 , v3 , v2 , v3 , v1 ,
> FIRST , v1 , FLOAT , INT , v2 , v3 , VERSION , v2 , FLOAT , INT , v1 , NO ,
> ROW , v3 , v2 ) ORDER BY v2 , v2 ;
> ```

Hmm, were you using a fuzzer to generate this query? It would sure be
useful to have it process some more and see what other crashes it
discovers.

Your example can be reduced to this, which already crashes the server:

SELECT * FROM XMLTABLE (ROW () passing null COLUMNS v1 TIMESTAMP, v2 int) AS f (v1, v2, v3);

and with this it is clear that the problem is that the alias list is too
long for the COLUMNS specification of the XMLTABLE function. This can
be avoided by throwing an error:

diff --git a/src/backend/parser/parse_relation.c b/src/backend/parser/parse_relation.c
index 7465919044..6c817a9c55 100644
--- a/src/backend/parser/parse_relation.c
+++ b/src/backend/parser/parse_relation.c
@@ -2001,6 +2001,12 @@ addRangeTableEntryForTableFunc(ParseState *pstate,
eref->colnames = list_concat(eref->colnames,
list_copy_tail(tf->colnames, numaliases));

+ if (numaliases > list_length(tf->colnames))
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("%s function has %d columns available but %d columns specified",
+ "XMLTABLE", list_length(tf->colnames), numaliases)));
+
rte->eref = eref;

/*

(Obviously, no regression test changes output after this patch.)

This mirrors what happens when you give too many aliases to tables or
other things. (In pg15 and up, it needs to be aware of JSON_TABLE too.
I made this on pg14.)

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Uno puede defenderse de los ataques; contra los elogios se esta indefenso"