pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: krking@zju.edu.cn
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17480: Assertion failure in parse_relation.c
Date: Sun, 15 May 2022 12:42:10 +0200
Message-ID: <202205151042.jjhnmhpsanbl@alvherre.pgsql> (raw)
In-Reply-To: <27736.1652227455@sss.pgh.pa.us>

On 2022-May-10, Tom Lane wrote:

> 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.

That makes sense; I ended up with the attached patch, in which I also
attempt to add regression test cases to cover all the cases.

I find that the check in addRangeTableEntryForValues is dead code,
because both callers pass a NULL Alias.  I find no way to give VALUES an
alias directly.  This has annoyed me in the past (not a big deal tbh),
but that makes me refrain from suggesting to removing the code.

We do get the correct error with this query,
  select * from (values (1)) as f (a, b);
but that is coming from addRangeTableEntryForSubquery.

This is backpatchable (sans the JSON_TABLE bits).  I'll attempt to get
it pushed later today.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"People get annoyed when you try to debug them."  (Larry Wall)

Attachments:

  [text/x-diff] 0001-Enforce-column-list-length-in-XMLTABLE-JSON_TABLE.patch (0B, ../202205151042.jjhnmhpsanbl@alvherre.pgsql/2-0001-Enforce-column-list-length-in-XMLTABLE-JSON_TABLE.patch)
  download

view thread (5+ messages)  latest in thread

Message-ID: <202205151042.jjhnmhpsanbl@alvherre.pgsql>
Permalink:  ../202205151042.jjhnmhpsanbl@alvherre.pgsql/
Also on:    postgresql.org/message-id/202205151042.jjhnmhpsanbl@alvherre.pgsql

 ·  · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: alvherre@alvh.no-ip.org, tgl@sss.pgh.pa.us, krking@zju.edu.cn, pgsql-bugs@lists.postgresql.org
  Subject: Re: BUG #17480: Assertion failure in parse_relation.c
  In-Reply-To: <202205151042.jjhnmhpsanbl@alvherre.pgsql>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox