Thread: updatable view set default interact with base rel generated stored columns

hi.
While reviewing virtual generated columns,
I find some issues with the updatable view interacting with stored
generated columns.

-----------------------
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);
-----------------------

"alter view rw_view1 alter column b set default 11.1;"
because rw_view1 view relation in ATExecColumnDefault
TupleDesc->attgenerated == '\0',
otherwise it can error out in ATExecColumnDefault.
Now after we set default, we cannot insert any value to rw_view1,
which makes it not updatable.



jian he <jian.universality@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