Re: [PATCH] Add pg_get_policy_ddl() function to reconstruct CREATE POLICY statement

I fixed two minor changes. The *v17* patch is ready for review/commit.

On Sun, Jul 12, 2026 at 8:08 PM Rui Zhao <zhaorui126(at)gmail(dot)com> wrote:

> Hi Akshay,
>
> v16 fixes both points from my last mail. Verified on master 5f14f82280:
> builds, rowsecurity passes, and the s1.f/s2.f case now round-trips under a
> hostile search_path. Nice that the rls_s1/rls_s2 test pins it.
>
> I also diffed the generated DDL against pg_dump for the policies in the RLS
> regression tests and pg_dump's own dump-test corpus (002_pg_dump.pl): they
> match in every case except multi-role ordering (e.g. rls_p8 -- the function
> keeps the declared order, TO regress_rls_dave, regress_rls_alice, while
> pg_dump
> sorts by role OID), which doesn't matter since role order in a policy isn't
> significant.
>
> One thing left over from point 1: func-info.sgml doesn't state that object
> references in the output are always schema-qualified. That's the function's
> contract now, and it differs from pg_get_viewdef / ruledef (which follow
> the
> caller's search_path), so a sentence would help. Empty search_path is also
> exactly what pg_dump uses (ALWAYS_SECURE_SEARCH_PATH_SQL), so this is the
> right call.
>
> A tiny style nit, in pg_get_policy_ddl_internal():
>
> Assert(!attrIsNull);
> {
> ArrayType *policy_roles = DatumGetArrayTypeP(valueDatum);
>
> a blank line after the Assert would read a bit better.
>
> Neither is a blocker -- looks ready to me.
>
> Regards,
> Rui
>