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

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

Check.

> This can be avoided by throwing an error:

+1, but you should match the ERRCODE thrown by buildRelationAliases,
that is ERRCODE_INVALID_COLUMN_REFERENCE.

Looking at the other addRangeTableEntry* functions,
addRangeTableEntryForJoin seems to similarly lack a defense
against too many aliases.  Testing shows that the case is covered
elsewhere:

regression=# select * from (int8_tbl i cross join int4_tbl j) ss(a,b,c,d) limit 2;
ERROR:  column alias list for "ss" has too many entries
regression=# \errverbose
ERROR:  42601: column alias list for "ss" has too many entries
LOCATION:  transformFromClauseItem, parse_clause.c:1458

but this is randomly different both in the message wording and in the
choice of ERRCODE.  I wonder if we shouldn't harmonize that, and maybe
move detection of the case to addRangeTableEntryForJoin for consistency
with the other cases.

            regards, tom lane



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

Предыдущее
От: Stefan Pastrilov
Дата:
Сообщение: Re: BUG #17478: Missing documents in the index after CREATE INDEX CONCURRENTLY (but existing in the table)
Следующее
От: Ram Pratap Maurya
Дата:
Сообщение: Posgresql-13 Bug (idle_in_transaction_session_timeout)