Re: BUG #19791: ALTER COLUMN TYPE fails on an INCLUDE column of an index used by a foreign key

On Fri, Oct 23, 2026 at 1:41 PM PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
>
> The following bug has been logged on the website:
>
> Bug reference: 19791
> Logged by: Alperen Keles
> Email address: alpkeles99(at)gmail(dot)com
> PostgreSQL version: 18.6
> Operating system: macOS 26.7 arm64
> Description:
>
> Hello,
>
> Changing the type of a non-key (INCLUDE) column of a unique index
> fails when a foreign key references the key columns of that index:
>
> CREATE TABLE p (a int4, b int4);
> CREATE UNIQUE INDEX p_u ON p (a) INCLUDE (b);
> CREATE TABLE c (a int4 REFERENCES p (a));
> ALTER TABLE p ALTER COLUMN b TYPE int8;
> ERROR: cannot drop index p_u because other objects depend on it
> DETAIL: constraint c_a_fkey on table c depends on index p_u
> HINT: Use DROP ... CASCADE to drop the dependent objects too.
>
> The same happens with UNIQUE (a) INCLUDE (b) and PRIMARY KEY (a)
> INCLUDE (b) constraints ("cannot drop constraint ..."), with a
> partitioned referenced table, with a self-referencing foreign key,
> with ALTER COLUMN b SET EXPRESSION on a stored generated column, and
> with changes that need no rewrite, such as varchar(5) -> varchar(10)
> or only a new COLLATE on b.
>
> It works without the foreign key (the index is rebuilt), when the
> key column a is altered instead (index and foreign key are rebuilt),
> and when both are altered in one statement:
>
> ALTER TABLE p ALTER COLUMN a TYPE int8, ALTER COLUMN b TYPE int8;
> ALTER TABLE
>
> The ALTER TABLE documentation says indexes and simple table
> constraints involving the column are converted automatically.
>
> As far as I can tell, RememberAllDependentForRebuilding() collects
> only the direct pg_depend dependents of the altered column. The
> index depends on a and b, but the foreign key depends only on p.a
> and on the index, so it is not collected when b is altered.
> ATPostAlterTypeCleanup() then drops the index with DROP_RESTRICT
> ("nothing else should be depending on these objects"), and the
> foreign key's dependency on the index makes that fail. Before
> INCLUDE, a foreign key could only depend on an index whose columns
> were all referenced by it.
>
> Reproduced on 18.6 (REL_18_STABLE a85b5523e67), master 158b6d5109f
> and 11.22, macOS arm64.
>

Thanks for reporting, yes your analysis looks correct to me. And
IMHO, To fix, whenever an index is remembered for rebuilding,either
directly or as the index of a constraint being rebuilt, also remember
any foreign key constraints that depend on it. They are then dropped
and re-added together with the index, the same way as when a key
column is altered.

I have attached a patch to fix it. If we think this is the right
approach, I will also add a test case.

--
Regards,
Dilip Kumar
Google