From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | jian he <jian(dot)universality(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: updatable view set default interact with base rel generated stored columns |
Date: | 2024-09-05 13:58:36 |
Message-ID: | 1830610.1725544716@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
jian he <jian(dot)universality(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bertrand Drouvot | 2024-09-05 14:14:47 | Re: per backend I/O statistics |
Previous Message | jian he | 2024-09-05 13:50:26 | ATExecColumnDefault comments |