Thread

Re: let ALTER COLUMN SET DATA TYPE cope with POLICY dependency

jian he <jian.universality@gmail.com> — 2025-12-24T02:49:57Z

hi.

main difference with v2:
ALTER COLUMN SET DATA TYPE will fail for policy containing sublink.

CREATE TABLE t(a int);
CREATE TABLE t1(a int);
CREATE POLICY p2 ON t1 AS PERMISSIVE USING ((SELECT t.a IS NOT NULL FROM t));
ALTER TABLE t ALTER COLUMN a SET DATA TYPE INT8;
ERROR:  cannot alter type of a column used by a policy definition when
the policy contains subquery
DETAIL:  policy p2 on table t depends on column "a"

If the above example does not fail, we would also need to acquire an
AccessExclusiveLock on table "t1" which does not seem ideal.  Even if this is
ok, We use the recreated policy definition, CreatePolicyStmt does not carry all
referenced OID information. As a result, re-parsing and analyzing the policy
qual or WITH CHECK qual would inevitably lead to repeated RangeVar name lookup
issue


The attached patch will let ALTER COLUMN SET DATA TYPE work fine for policy
dependent objects, if the policy qual or with check qual does not have Sublink,
otherwise it will error out.

v3-0001, v3-0002 is used in [1] too.
[1]: https://postgr.es/m/CACJufxFuEOB-i2z2qhyCG=dGwDf7g6Fs_o8cz=BUi76UuUFSOA@mail.gmail.com


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