Thread

Re: [PATCH] Rebuild CHECK constraints after generated column SET EXPRESSION

jian he <jian.universality@gmail.com> — 2026-05-13T05:19:36Z

Hi.

In case you are wondering, I already handled the whole-row cases for
ALTER TABLE DROP COLUMN and ALTER COLUMN SET DATA TYPE in
https://commitfest.postgresql.org/patch/5988 and
https://commitfest.postgresql.org/patch/6055

However, I missed the ALTER COLUMN SET EXPRESSION scenario.

RememberAllDependentForRebuilding with (attnum = 0) is essentially
asking any objects depend on this relation,
It will certainly catch many whole-row referenced dependent objects,
however, I wouldn’t be surprised if unintended corner cases exist.

CREATE TABLE r2 (a int, b int GENERATED ALWAYS AS (a * 10) STORED);
ALTER TABLE r2 ADD CONSTRAINT cc CHECK (a IS NOT NULL);
CREATE INDEX r2_idx ON r2 (a);
CREATE POLICY p3 ON r2 AS PERMISSIVE USING (a IS NOT NULL);
select classid::regclass, * from pg_depend where refobjid =
'r2'::regclass::oid and classid in ('pg_policy'::regclass);

The examples above show that RLS policies can have two dependencies on the
relation: one on the specific column, and another on the relation itself.
``RememberAllDependentForRebuilding with (attnum = 0)`` cannot cope with this.

ATRewriteTables->finish_heap_swap->reindex_relation may reindex the
relation, but
AlteredTableInfo->changedIndexOids should still remember the whole-row
Var references index objects.

For ALTER COLUMN SET EXPRESSION, no need to worry about whole-row
referenced triggers.BEFORE trigger referencing the whole-row
(including generated column) is not allowed (see
CreateTriggerFiringOn: ```if (!whenClause &&stmt->whenClause)```), and
ALTER COLUMN SET EXPRESSION will work fine with AFTER
triggersthat have whole-row reference.

The attached v2 includes support for ALTER COLUMN SET EXPRESSION on columns
referenced by whole-row indexes, check constraints, and RLS policies.

The code pattern is more or less simialr to
https://commitfest.postgresql.org/patch/6055.
I should rebase https://commitfest.postgresql.org/patch/6055 BTW.



--
jian
https://www.enterprisedb.com/