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

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.

Found with a query fuzzer.

Regards,
Alperen Keles