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
- make-expandRTE-ignore-new-columns.patch (text/x-diff) patch
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
-
Fix crash when columns have been added to the end of a view.
- d5b760ecb5e1 11.0 landed
- ddde3b4f3e88 10.1 landed
- acd3287e437e 9.5.10 landed
- 9d15b8b36a91 9.3.20 landed
- 80e79718d0ea 9.2.24 landed
- 7e5e8b36d478 9.6.6 landed
- 66104119e1fb 9.4.15 landed