jian he <jian.universal...@gmail.com> writes:
> -----------------------
> drop table if exists base_tbl cascade;
> CREATE TABLE base_tbl (a int, b int GENERATED ALWAYS AS (22) stored, d
> int default 22);
> create view rw_view1 as select * from base_tbl;
> insert into rw_view1(a) values (12) returning *;
> alter view rw_view1 alter column b set default 11.1;
> insert into rw_view1(a,b,d) values ( 12, default,33) returning *;
> insert into rw_view1(a,d) values (12,33) returning *;
> insert into rw_view1 default values returning *;
> SELECT events & 4 != 0 AS can_upd,
> events & 8 != 0 AS can_ins,
> events & 16 != 0 AS can_del
> FROM pg_catalog.pg_relation_is_updatable('rw_view1'::regclass, false)
> t(events);
> -----------------------
I don't really see anything wrong here. Yeah, you broke insertions
into the view yet it still claims to be updatable. But there is
nothing about the view that makes it not-updatable; it's something
that happens at runtime in the base table that is problematic.
If we try to detect all such cases we'll be solving the halting
problem. That is, I don't see any functional difference between
this example and, say, a default value attached to the view that
violates a CHECK constraint of the base table.
regards, tom lane
