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

Tom Lane <tgl@sss.pgh.pa.us>

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>
Date: 2017-10-26T22:04:59Z
Lists: pgsql-bugs

Attachments

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

Commits

  1. Fix crash when columns have been added to the end of a view.