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

On Mon, Jun 30, 2025 at 10:23 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> jian he <jian(dot)universality(at)gmail(dot)com> writes:
> > This issue also applies to tab->changedStatisticsOids
> > and tab->changedIndexOids in ATPostAlterTypeCleanup.
>
> Oh, indeed :-(
>
> > We likely need to do the same as well.
>
> I'm about done for the day --- you want to prepare the patch?
>
hi.

I added 2 more error case tests in alter_table.sql

SET EXPRESSION both can have this issue.
so i also add more test cases for stored/virtual generated columns.

ALTER TYPE | SET EXPRESSION
trigger related related index build, we use AccessExclusiveLock to
lock the related relation
trigger related related statistic build, we use
ShareUpdateExclusiveLock to lock the related relation

-----------------the following are attached patch commit messages
ALTER TYPE or SET EXPRESSION may necessitate rebuilding constraints, indexes, or
statistics for related tables. As we may not acquire locks on these related
relations before ATPostAlterTypeCleanup, we obtain appropriate locks here.

This also means that for virtual generated columns, we still need to call
RememberAllDependentForRebuilding, even though indexes and statistics cannot
currently be created on them.

When ALTER TYPE or SET EXPRESSION triggers a statistics rebuild for another
table, we use ShareUpdateExclusiveLock to lock the related table, consistent
with the locking approach in RemoveStatisticsById, AT_SetStatistics, and
CreateStatistics.
----------------