Re: Proof of concept: auto updatable views [Review of Patch] - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proof of concept: auto updatable views [Review of Patch]
Date
Msg-id 16135.1352409203@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proof of concept: auto updatable views [Review of Patch]  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: Proof of concept: auto updatable views [Review of Patch]  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: AutoVacuum starvation from sinval messages
Next
From: Jeff Janes
Date:
Subject: Re: AutoVacuum starvation from sinval messages