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
Subject: Re: BUG #17480: Assertion failure in parse_relation.c
In-reply-to: <202205101050.sepjyffoevsy@alvherre.pgsql>
References: <202205101050.sepjyffoevsy@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
	message dated "Tue, 10 May 2022 12:50:57 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <27735.1652227455.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 10 May 2022 20:04:15 -0400
Message-ID: <27736.1652227455@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/27736.1652227455%40sss.pgh.pa.us>
Precedence: bulk

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=3D# 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=3D# \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