On Fri, May 25, 2018 at 11:21 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> For reasons that I'm not quite sure about, the following test case >> crashes in v11, but not earlier versions: > > Crashes just fine in prior versions for me, at least as far back as 9.3, > but probably much further. Note that I was doing an extra select fun() > right after creating the function --- I don't think that should affect > the behavior, but maybe it does? Or maybe you were testing non-assert > builds?
Oops, yeah, my back-branch builds were without assertions. > The core problem here seems to be that exec_stmt_execsql sets mod_stmt > once when the query is first planned, and doesn't account for the idea > that the statement's classification might change later. But adding > (or removing) a DO INSTEAD rule can indeed change that. > > Looking at what mod_stmt is used for, we've got > > (1) the Assert that's crashing, and its siblings, which are just meant > to cross-check that mod_stmt is consistent with the SPI return code. > > (2) two places that decide to enforce STRICT behavior if mod_stmt > is true. > > I think we could just drop those Asserts. As for the other things, > maybe we should force STRICT on the basis of examining the raw > parsetree (which really is immutable) rather than what came out of > the planner. It doesn't seem like a great idea that INSERT ... INTO > should stop being considered strict if there's currently a rewrite > rule that changes it into something else. Yes, that does sound like surprising behavior. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
