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

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: BUG #17480: Assertion failure in parse_relation.c
Дата
Msg-id 202205101050.sepjyffoevsy@alvherre.pgsql
обсуждение исходный текст
Ответ на BUG #17480: Assertion failure in parse_relation.c  (PG Bug reporting form <noreply@postgresql.org>)
Ответы Re: BUG #17480: Assertion failure in parse_relation.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
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"



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Richard Guo
Дата:
Сообщение: Re: BUG #17479: "plan should not reference subplan's variable" when calling `grouping` on result of subquery
Следующее
От: Richard Guo
Дата:
Сообщение: Re: BUG #17479: "plan should not reference subplan's variable" when calling `grouping` on result of subquery