Re: BUG #18970: Atempt to alter type of table column used in row type with check leads to assertion failure
От | Tom Lane |
---|---|
Тема | Re: BUG #18970: Atempt to alter type of table column used in row type with check leads to assertion failure |
Дата | |
Msg-id | 3266569.1751399577@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18970: Atempt to alter type of table column used in row type with check leads to assertion failure (jian he <jian.universality@gmail.com>) |
Список | pgsql-bugs |
jian he <jian.universality@gmail.com> writes: > On Mon, Jun 30, 2025 at 11:14 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> ... I think that is in fact wrong. The implementation restriction >> we have is that we lack code to run around and physically change >> the stored values of columns that are not top-level table columns. >> However, in the case of a virtual column we don't need to change >> anything about the storage: once we've fixed the catalog metadata, >> we're done. So I'm not seeing the need to add all this stuff >> other than the additional locking calls. > CREATE TABLE t1(a int generated always as ('1') stored); > CREATE TABLE t2(b t1 CHECK ((b).a IS NOT NULL)); > INSERT INTO t2 default values returning *; > ERROR: new row for relation "t2" violates check constraint "t2_b_check" > DETAIL: Failing row contains (null). > INSERT INTO t2 values '(1)' returning *; > ALTER TABLE t1 ALTER COLUMN a SET EXPRESSION AS (NULL); > Currently we disallow this "SET EXPRESSION AS". > I am wondering why we disallow it? That is an interesting question. AFAICT we treat the GENERATED clause as being like a constraint. We don't apply constraints of a table to uses of its composite type, so in the above example t2's b.a does not pay any attention to the GENERATED clause; it just acts as an ordinary "int" column. So it's not very clear why we should forbid ALTER COLUMN a SET EXPRESSION because of t2. If the idea was to leave the door open for a future change of that behavior (that is, to start propagating the GENERATED clause to uses of the composite type), I think that ship has already sailed. So, rather than add a new restriction for VIRTUAL generated columns, I'd be inclined to remove the one for STORED columns. At least if the argument is to make them act the same. If we're okay with them working differently then we don't have to do anything. > at that time, I was mainly initrucugged by this comment about > composite type default > in ATRewriteTables: > * If we change column data types, the operation has to be propagated > * to tables that use this table's rowtype as a column type. > * tab->newvals will also be non-NULL in the case where we're adding a > * column with a default. We choose to forbid that case as well, > * since composite types might eventually support defaults. That (propagating defaults to composite types) again strikes me as a ship that sailed long ago. Quite aside from the implementation issues that would arise, we'd be changing longstanding behavior. Peter, what's your opinion? regards, tom lane
В списке pgsql-bugs по дате отправления: