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?
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.
regards, tom lane
