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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: krking@zju.edu.cn, pgsql-bugs@lists.postgresql.org
Date: 2022-05-11T00:04:15Z
Lists: 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



Commits

  1. Check column list length in XMLTABLE/JSON_TABLE alias