Re: Assertion failure in plpgsql with INSTEAD OF rule

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> If _SPI_execute_plan reaches the above "if" and sets "my_res = res",
> SPI_processed is left at 0. So FOUND is always set to false if the
> rewritten command type doesn't match the original.

Right, and I think that's probably sane behavior. The original command
got rewritten to nothing, therefore it processed zero rows. I'd be
happy with code that guaranteed that FOUND got set false in that case.
The point I'm making is that the code doesn't guarantee it now (and
would not do so after removing those Asserts either). Consider

create rule r1 as on insert to foo do instead notify foo_insert;

As implemented, this would send us through the SPI_OK_UTILITY path
and nothing happens to FOUND. I say that's a bug.

So what I'm thinking is:

1. We can't redefine the SPI interface in back branches, so there's
probably little alternative but to remove those Asserts there.

2. In HEAD, I think we should have SPI return a new SPI_OK_REWRITTEN
code for this case, and have plpgsql respond to that by always setting
found = false. With that, the Asserts can stay (in fact the new path
should assert !mod_stmt, since it shouldn't have found any canSetTag
query).

regards, tom lane