On Friday, April 11, 2025, Tom Lane <t...@sss.pgh.pa.us> wrote: > jian he <jian.universal...@gmail.com> writes: > > CREATE TABLE gtest1 (a int, b int GENERATED ALWAYS AS (a * 2) STORED); > > CREATE VIEW gtest1v AS SELECT * FROM gtest1; > > ALTER VIEW gtest1v ALTER COLUMN b SET DEFAULT 100; > > > INSERT INTO gtest1v VALUES (8, DEFAULT) returning *; > > ERROR: cannot insert a non-DEFAULT value into column "b" > > DETAIL: Column "b" is a generated column. > > > we can make > > ALTER VIEW gtest1v ALTER COLUMN b SET DEFAULT 100; > > error out, > > This is not an improvement over having the error happen at run time. > > (1) What if the state of the underlying column changes between the > ALTER VIEW and the INSERT? Either you have rejected something > that could have worked, or in the other direction you're going to get > the run-time error anyway. >
I concur. The view is only loosely coupled to the base relation, via the rewrite rule which is applied at runtime. Putting checks in place that strongly couples the two relations adds a coupling burden that we are better off avoiding. David J.
