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

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

In response to

Browse pgsql-hackers by date

  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