From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | krking(at)zju(dot)edu(dot)cn, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17480: Assertion failure in parse_relation.c |
Date: | 2022-05-11 00:04:15 |
Message-ID: | 27736.1652227455@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ram Pratap Maurya | 2022-05-11 07:52:24 | Posgresql-13 Bug (idle_in_transaction_session_timeout) |
Previous Message | Tom Lane | 2022-05-10 23:42:32 | Re: Query generates infinite loop |