Re: Proof of concept: auto updatable views [Review of Patch]

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Peter Eisentraut <peter_e@gmx.net>, Amit kapila <amit.kapila@huawei.com>, "robertmhaas@gmail.com" <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2012-11-08T21:13:23Z
Lists: pgsql-hackers
Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> create table bar(a int);
> create view bar_v as select * from bar;
> create rule bar_r as on insert to bar_v where new.a < 0 do instead nothing;
> insert into bar_v values(-1),(1);
> select * from bar_v;
>  a
> ---
>  1
> (1 row)

> Having that put both -1 and 1 into bar seems completely wrong to me.

Right now, what you get from that is

ERROR:  cannot insert into view "bar_v"
HINT:  You need an unconditional ON INSERT DO INSTEAD rule or an INSTEAD OF INSERT trigger.

and (modulo the contents of the HINT) I think that's still what you
should get.  If the user has got some DO INSTEAD rules we should not be
second-guessing what should happen.

> This also seems like a much more plausible case where users might have
> done something like this with a trigger-updatable view, so I don't
> think the backwards-compatibility argument can be ignored.

I think the most reasonable backwards-compatibility argument is that we
shouldn't change the behavior if there are either INSTEAD rules or
INSTEAD triggers.  Otherwise we may be disturbing carefully constructed
behavior (and no, I don't buy that "throw an error" couldn't be what the
user intended).

			regards, tom lane