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

On Fri, Sep 12, 2025 at 4:19 PM jian he <jian(dot)universality(at)gmail(dot)com> wrote:
>
> hi.
>
> in [1],
> RememberAllDependentForRebuilding
> /*
> * A policy can depend on a column because the column is
> * specified in the policy's USING or WITH CHECK qual
> * expressions. It might be possible to rewrite and recheck
> * the policy expression, but punt for now. It's certainly
> * easy enough to remove and recreate the policy; still, FIXME
> * someday.
> */
> After 11 year, I am trying to allow column type changes to cope with
> security policy dependencies.
>
> CREATE TABLE s (a int, b int);
> CREATE POLICY p2 ON s USING (s.b = 1);
> --master branch will result error
> ALTER TABLE s ALTER COLUMN b SET DATA TYPE INT8;
> ERROR: cannot alter type of a column used in a policy definition
> DETAIL: policy p2 on table s depends on column "b"
>
> with the attached patch, ALTER TABLE SET DATA TYPE can cope with columns that
> have associated security policy.
> The above ALTER TABLE SET DATA TYPE will just work fine.
> The code roughly follows how statistics are recreated after a column
> data type change.

v1 coding is not as aligned as with how statistics are recreated after
data changes.
For example, we have transformStatsStmt, but don't have transformPolicyStmt.

v2-0001 refactor CreatePolicy.
introduce transformPolicyStmt, very similar to transformStatsStmt,
and we don't need two ParseState (qual_pstate, with_check_pstate).
but we need one ParseState for recordDependencyOnExpr.

v2-0002 is the same as v1-0001 mostly, using transformPolicyStmt in
ATPostAlterTypeParse.