On Fri, May 25, 2018 at 11:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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
