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 <[email protected]> wrote: > Hi all, > > On Wed, Jul 1, 2026 at 4:01 PM Akshay Joshi > <[email protected]> wrote: > > > > > > > > On Wed, Jul 1, 2026 at 2:44 PM solai v <[email protected]> wrote: > >> > >> Hi all, > >> > >> > >> On Tue, Jun 30, 2026 at 4:48 PM Akshay Joshi > >> <[email protected]> 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 >
v15-0001-Add-pg_get_policy_ddl-to-reconstruct-CREATE.patch
Description: Binary data
