Re: [BUGS] BUG #14876: Segmentation fault with JSONB column used in store proc that gets used by view and later altered

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

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 == 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)));

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