Re: BUG #18970: Atempt to alter type of table column used in row type with check leads to assertion failure

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: jian he <jian(dot)universality(at)gmail(dot)com>
Cc: exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18970: Atempt to alter type of table column used in row type with check leads to assertion failure
Date: 2025-06-30 15:14:43
Message-ID: 2828229.1751296483@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

jian he <jian(dot)universality(at)gmail(dot)com> writes:
> SET EXPRESSION both can have this issue.
> so i also add more test cases for stored/virtual generated columns.

This patch is a lot larger than I was expecting, and I think it's
misguided. You argue that

+ * Changing a virtual generated column's expression is akin to altering its
+ * type, requiring a call to find_composite_type_dependencies to check if
+ * the virtual generated column is used in any table.
+ * Therefore we need add this defval to tab->newvals for virtual generated
+ * column too, so Phase3 will call find_composite_type_dependencies.

but 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.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message jian he 2025-07-01 03:25:20 Re: BUG #18970: Atempt to alter type of table column used in row type with check leads to assertion failure
Previous Message Tom Lane 2025-06-30 14:56:58 Re: BUG #18973: The default enable_material=ON affects the cost estimation of optimizer, resulting in 10968x slow