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
-
Check column list length in XMLTABLE/JSON_TABLE alias
- ba83de8ada5b 11.17 landed
- ade17703def9 12.12 landed
- 94edb85d253e 14.4 landed
- 80656f00f856 13.8 landed
- 16cb7db34f3c 10.22 landed
- 0fbf01120023 15.0 landed