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

From: jian he <jian(dot)universality(at)gmail(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: let ALTER COLUMN SET DATA TYPE cope with POLICY dependency
Date: 2025-12-24 02:49:57
Message-ID: CACJufxGOVnwYA90nYfRAGue6e_UYNm_mSnaNEU1npfgjtydb=w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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/

Attachment Content-Type Size
v3-0003-ALTER-TABLE-command-to-change-policy.patch text/x-patch 33.3 KB
v3-0002-refactoring-CreatePolicy-split-policy-qual-check-qual.patch text/x-patch 10.8 KB
v3-0001-add-RangeTblEntry-to-CreatePolicyStmt.patch text/x-patch 3.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message zengman 2025-12-24 02:50:16 Re: Refactor query normalization into core query jumbling
Previous Message Tom Lane 2025-12-24 02:47:55 Re: More const-marking cleanup