From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | jian he <jian(dot)universality(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: disallow ALTER VIEW SET DEFAULT when the corresponding base relation column is a generated column |
Date: | 2025-04-11 14:07:32 |
Message-ID: | 835270.1744380452@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:
> 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.
(2) I don't see anything wrong or surprising about the run-time
error anyway, thus I fail to see that this is an improvement,
even aside from (1).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Antonin Houska | 2025-04-11 14:12:20 | Conflicting updates of command progress |
Previous Message | Tom Lane | 2025-04-11 14:00:59 | Re: COALESCE with single argument looks like identity function |