| From: | Quan Zongliang <quanzongliang(at)yeah(dot)net> |
|---|---|
| To: | Bryan Green <dbryan(dot)green(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH] Add pg_get_role_ddl() functions for role recreation |
| Date: | 2025-11-06 07:20:25 |
| Message-ID: | cc50e181-156c-4cbc-a502-9b4c381458d5@yeah.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 10/25/25 4:03 AM, Bryan Green wrote:
> Attached is a patch adding two new functions for generating DDL to
> recreate roles: pg_get_role_ddl() and pg_get_role_ddl_statements().
>
It is no longer apply to the latest code. Could you rebase this?
> These functions return the CREATE ROLE statement and any ALTER ROLE SET
> configuration parameters needed to recreate a role. The former returns
> everything as a single text string, while the latter returns each
> statement as a separate row for easier programmatic processing.
>
> The main use case is dumping role definitions for migration or backup
> purposes without needing pg_dumpall. The functions handle all role
> attributes (LOGIN, SUPERUSER, etc.) and both role-wide and
> database-specific configuration parameters.
>
> We intentionally don't include passwords, since we can only see the
> hashed values. System roles (names starting with "pg_") are rejected
> with an error, as users shouldn't be recreating those anyway.
>
> To test:
>
> CREATE ROLE testrole LOGIN CREATEDB CONNECTION LIMIT 5;
> ALTER ROLE testrole SET work_mem TO '64MB';
> SELECT pg_get_role_ddl('testrole');
>
> Should produce:
>
> CREATE ROLE testrole LOGIN NOSUPERUSER CREATEDB NOCREATEROLE INHERIT
> NOREPLICATION NOBYPASSRLS CONNECTION LIMIT 5;
> ALTER ROLE testrole SET work_mem TO '64MB';
>
> The patch includes regression tests covering various role configurations.
>
> Co-authored-by: Mario Gonzalez and Bryan Green.
>
> Comments?
>
> BG
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mats Kindahl | 2025-11-06 07:37:58 | Re: Use stack-allocated StringInfoData |
| Previous Message | jian he | 2025-11-06 07:16:36 | Re: inconsistent tableoid handling in COPY WHERE clause |