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
|
Список | 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 по дате отправления: