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

All,

I found that OID 6517 was already taken by the max(uuid) aggregate. I've
reassigned pg_get_policy_ddl to OID 9683.
The v15 patch is ready for review and commit.

On Wed, Jul 1, 2026 at 5:01 PM solai v <solai(dot)cdac(at)gmail(dot)com> wrote:

> Hi all,
>
> On Wed, Jul 1, 2026 at 4:01 PM Akshay Joshi
> <akshay(dot)joshi(at)enterprisedb(dot)com> wrote:
> >
> >
> >
> > On Wed, Jul 1, 2026 at 2:44 PM solai v <solai(dot)cdac(at)gmail(dot)com> wrote:
> >>
> >> Hi all,
> >>
> >>
> >> On Tue, Jun 30, 2026 at 4:48 PM Akshay Joshi
> >> <akshay(dot)joshi(at)enterprisedb(dot)com> wrote:
> >> >
> >> > All,
> >> >
> >> > I've updated the patch to align with the interface change introduced
> by commit d6ed87d1989 (Andrew Dunstan, 2026-06-26 "Use named boolean
> parameters for pg_get_*_ddl option arguments").
> >> >
> >> > That commit replaced the VARIADIC text[] alternating key/value option
> interface with typed named boolean parameters across pg_get_role_ddl(),
> pg_get_tablespace_ddl(), and pg_get_database_ddl(), removing the
> DdlOption/parse_ddl_options() machinery in favour of direct
> PG_GETARG_BOOL() calls.
> >> >
> >> > Updated patch v14 is ready for review/commit.
> >> >
> >>
> >>
> >> I reviewed and tested the v14 patch on the latest master. The patch
> >> applied cleanly, built successfully, and passed make check without any
> >> regression failures. I verified the new function signature and
> >> confirmed that pg_get_policy_ddl() now uses the new interface with the
> >> boolean DEFAULT false argument. Also I tested the function with a
> >> variety of row-level security policies, including: Basic policy
> >> reconstruction, PERMISSIVE and RESTRICTIVE policies, Different command
> >> types (SELECT, INSERT, UPDATE, DELETE), Policies with multiple roles
> >> and the PUBLIC role, Quoted table, policy, and role names, USING and
> >> WITH CHECK clauses, Complex expressions including EXISTS, nested
> >> subqueries, CASE expressions, COALESCE, ANY/ALL operators, and boolean
> >> expressions, NULL inputs, invalid relation names, and non-existent
> >> policies. The generated DDL was correct as per the intent, and the
> >> expected errors were verified for the invalid inputs. I also verified
> >> that the generated DDL is executable by dropping an existing policy,
> >> recreating it using the output of pg_get_policy_ddl(), and confirming
> >> that the recreated policy was reconstructed successfully again by the
> >> function.
> >> One observation I noted is that for policies using default attributes
> >> (TO PUBLIC and AS PERMISSIVE), the generated DDL omits those clauses
> >> and produces a semantically equivalent statement which seems
> >> intentional but thought of sending it here for further clarification.
> >> Overall, I did not encounter any functional issues during testing. The
> >> patch looks good to me and worked as expected in all the scenarios I
> >> tested.
> >
> >
> > Yes, it's intentional for all pg_get_***_ddl functions. Clause with
> defaults won't be reconstructed.
> >>
> >>
>
> Ok. Thank you for the clarification.
>
> Regards,
> Solai
>