From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael.paquier@gmail.com>
cc: samuel.horwitz@gmail.com,
        PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Subject: Re: BUG #14876: Segmentation fault with JSONB column used in store
 proc that gets used by view and later altered
In-reply-to: <26672.1509050556@sss.pgh.pa.us>
References: <20171026184035.1471.82810@wrigleys.postgresql.org>
 <CAB7nPqTxBZ5GorM8bejJ0z1aQo0Z93ChRJ9gCV5zu8B=ZrARVg@mail.gmail.com>
 <26672.1509050556@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Thu, 26 Oct 2017 16:42:36 -0400"
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <31429.1509055479.0@sss.pgh.pa.us>
Date: Thu, 26 Oct 2017 18:04:59 -0400
Message-ID: <31441.1509055499@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-bugs-owner@postgresql.org

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <31429.1509055479.1@sss.pgh.pa.us>

I wrote:
> Thanks for posting the reproducer.  The attached seems to fix it, but
> now that I've seen this, I wonder if there are other similar cases.

After some not-very-exhaustive looking around, the only thing I've found
that seems closely related is expandRTE's behavior for a function
returning composite in an RTE_FUNCTION RTE.  It's clearly possible for
somebody to have added columns to the composite type since the calling
query was parsed, so there is a comparable hazard in that case as well.
But what that code path does is to ignore any columns beyond what it
saw originally (which it's memorialized in funccolcount; see the comment
for struct RangeTblFunction).

To be consistent with that, it seems like what the RTE_SUBQUERY case
ought to do is ignore columns beyond the length of eref->colnames.
This is probably less useful than what I posted first --- it means you
don't get to see any added columns in the result of "subqueryname.*".
But I doubt we want different behaviors in the two cases.

			regards, tom lane


------- =_aaaaaaaaaa0
Content-Type: text/x-diff; name="make-expandRTE-ignore-new-columns.patch";
	charset="us-ascii"
Content-ID: <31429.1509055479.2@sss.pgh.pa.us>
Content-Description: make-expandRTE-ignore-new-columns.patch
Content-Transfer-Encoding: quoted-printable

diff --git a/src/backend/parser/parse_relation.c b/src/backend/parser/parse=
_relation.c
index ca32a37..e89bebf 100644
*** a/src/backend/parser/parse_relation.c
--- b/src/backend/parser/parse_relation.c
*************** expandRTE(RangeTblEntry *rte, int rtinde
*** 2205,2213 ****
  					varattno++;
  					Assert(varattno =3D=3D te->resno);
=20=20
  					if (colnames)
  					{
- 						/* Assume there is one alias per target item */
  						char	   *label =3D strVal(lfirst(aliasp_item));
=20=20
  						*colnames =3D lappend(*colnames, makeString(pstrdup(label)));
--- 2205,2223 ----
  					varattno++;
  					Assert(varattno =3D=3D te->resno);
=20=20
+ 					/*
+ 					 * In scenarios where columns have been added to a view
+ 					 * since the outer query was originally parsed, there can
+ 					 * be more items in the subquery tlist than the outer
+ 					 * query expects.  We should ignore such extra column(s)
+ 					 * --- compare the behavior for composite-returning
+ 					 * functions, in the RTE_FUNCTION case below.
+ 					 */
+ 					if (!aliasp_item)
+ 						break;
+=20
  					if (colnames)
  					{
  						char	   *label =3D strVal(lfirst(aliasp_item));
=20=20
  						*colnames =3D lappend(*colnames, makeString(pstrdup(label)));

------- =_aaaaaaaaaa0
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

------- =_aaaaaaaaaa0--