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
Date: Thu, 26 Oct 2017 18:04:59 -0400
Message-ID: <31441.1509055499@sss.pgh.pa.us> (raw)
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-bugs>
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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugsAttachments:make-expandRTE-ignore-new-columns.patch (text/x-diff, 1.2K) downloaddiff --git a/src/backend/parser/parse_relation.c b/src/backend/parser/parse_relation.cindex 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 == te->resno);
if (colnames)
{
- /* Assume there is one alias per target item */
char *label = strVal(lfirst(aliasp_item));
*colnames = lappend(*colnames, makeString(pstrdup(label)));
--- 2205,2223 ----
varattno++;
Assert(varattno == te->resno);
+ /*+ * 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;+
if (colnames)
{
char *label = strVal(lfirst(aliasp_item));
*colnames = lappend(*colnames, makeString(pstrdup(label)));
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: tgl@sss.pgh.pa.us, michael.paquier@gmail.com
Subject: Re: BUG #14876: Segmentation fault with JSONB column used in store proc that gets used by view and later altered
In-Reply-To: <31441.1509055499@sss.pgh.pa.us>
* 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