Tom Lane wrote:
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.
Committed this.
2. In HEAD, I think we should have SPI return a new SPI_OK_REWRITTEN
code for this case, and have plpgsq
Heikki Linnakangas 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
Tom Lane wrote:
Heikki Linnakangas writes:
The problem is that mod_stmt is determined for the query that has
canSetTag set, but in case of an INSTEAD OF rule that rewrites the
statement into a different command, an INSERT into a DELETE in this
case, canSetTag is not set. The return code of SP
Heikki Linnakangas writes:
> The problem is that mod_stmt is determined for the query that has
> canSetTag set, but in case of an INSTEAD OF rule that rewrites the
> statement into a different command, an INSERT into a DELETE in this
> case, canSetTag is not set. The return code of SPI_execute_
This test case:
CREATE TABLE atable(n int);
CREATE TABLE btable(n int);
CREATE RULE insteadrule AS ON INSERT TO atable DO INSTEAD delete from
btable;
CREATE FUNCTION rulecrash() RETURNS void AS $$
begin
insert into atable values(1);
end;
$$ LANGUAGE plpgsql;
SELECT rulecrash();
Fails an a
