While testing something , I found that even after rule has dropped not able to insert data and in an another scenario , there is a Crash/
Please refer this scenario's -
1) Rows not inserted after dropping the RULE
postgres=# create table e(n int); CREATE TABLE postgres=# create rule e1 as on insert to e do instead nothing; CREATE RULE postgres=# create function e11(n int) returns int as $$ begin insert into e values(10); return 1; end; $$ language 'plpgsql'; CREATE FUNCTION postgres=# select e11(1); e11 ----- 1 (1 row)
postgres=# select e11(1); e11 ----- 1 (1 row)
postgres=# select * from e; => Expected , due to the RULE enforced n --- (0 rows)
postgres=# drop rule e1 on e; ==>Drop the rule DROP RULE
postgres=# select e11(1); =>again try to insert into table e11 ----- 1 (1 row)
postgres=# select * from e; =>This time , value should be inserted but still showing 0 row. n --- (0 rows)
2)Server crash (one time)
postgres=# create table en(n int); CREATE TABLE postgres=# create function en1(n int) returns int as $$ begin insert into en values(10); return 1; end; $$ language 'plpgsql'; CREATE FUNCTION postgres=# postgres=# select en1(1); en1 ----- 1 (1 row)
postgres=# select * from en; n ---- 10 (1 row)
postgres=# create rule en11 as on insert to en do instead nothing; CREATE RULE postgres=# select en1(1); ostgres=# select en1(1); TRAP: FailedAssertion("!(!stmt->mod_stmt)", File: "pl_exec.c", Line: 3721) server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request.
I have looked into this crash, seems like below assert in exec_stmt_execsql is not correct
case SPI_OK_REWRITTEN:
Assert(!stmt->mod_stmt);
In this issue first time execution of select en1(1); statement, stmt->mod_stmt is set to true for the insert query inside the function. Then before next execution we have created the rule "create rule en11 as on insert to en do instead nothing;". Because of this nothing will be executed and output will be SPI_OK_REWRITTEN. But we are asserting that stmt->mod_stmt should be false (which were set to true in first execution).
