Re: pg_get__*_ddl consolidation
Zsolt Parragi <zsolt.parragi@percona.com>
From: Zsolt Parragi <zsolt.parragi@percona.com>
To: Euler Taveira <euler@eulerto.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-03-20T22:29:29Z
Lists: pgsql-hackers
> I couldn't reproduce the failure. The non-fixed DateStyle is by design. It
> mimics pg_dumpall.
Sorry, I made a mistake while only copying the relevant parts of the
test case here. This is the correct test case:
SET DateStyle TO 'SQL, DMY'; -- change from default MDY to DMY
CREATE ROLE regress_datestyle_test VALID UNTIL '2030-12-31 23:59:59+00';
SELECT * FROM pg_get_role_ddl('regress_datestyle_test');
DROP ROLE regress_datestyle_test;
SET DateStyle TO 'SQL, MDY'; -- go back to default, or open a new
connection to use the generated command
-- try to run statement generated by pg_get_role_ddl
I'm not saying that this is necessarily wrong, but perhaps it's worth
mentioning somewhere?
> Since I don't know if you will use the testrole role to create testdb
> database or even if the testrole exists in the cluster, it shouldn't return the
> ALTER DATABASE testdb SET work_mem TO '512MB' (because that property belongs to
> testrole role).
Sorry, I wasn't specific previously, it returns the role specific
role, without the role specific condition:
CREATE DATABASE testdb;
CREATE ROLE testrole;
ALTER DATABASE testdb SET work_mem TO '256MB';
ALTER ROLE testrole IN DATABASE testdb SET work_mem TO '512MB';
SELECT pg_get_database_ddl('testdb');
pg_get_database_ddl
-------------------------------------------------------------------------------------------------------------------
CREATE DATABASE testdb WITH TEMPLATE = template0 ENCODING = 'UTF8'
LOCALE_PROVIDER = libc LOCALE = 'en_US.UTF-8';
ALTER DATABASE testdb OWNER = dutow;
ALTER DATABASE testdb SET work_mem TO '256MB';
ALTER DATABASE testdb SET work_mem TO '512MB';
> one way is to
> compare the output with pg_dump(all). Another point is that these functions can
> be used by a dump tool.)
I did my previous testing with this in mind.
Both the role specific database options and the role memberships are
related: I understand if you say that this is a design decision /
limitation. On the other hand if the goal is that users should be able
to replicate dump(all) with these functions, then we should have a
way to also get that information, either by providing two different
outputs, or by specific additional getter functions.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Use named boolean parameters for pg_get_*_ddl option arguments
- d6ed87d19890 19 (unreleased) landed
-
Convert ddlutils regression tests to TAP tests.
- c529ee38b9eb 19 (unreleased) landed
-
Fix pfree crash in pg_get_role_ddl() and pg_get_database_ddl().
- 1f108fc02ece 19 (unreleased) landed
-
Fixups for a4f774cf1c7
- 6c7bce28c83f 19 (unreleased) landed
-
Add infrastructure for pg_get_*_ddl functions
- 4881981f9202 19 (unreleased) landed
-
Add pg_get_database_ddl() function
- a4f774cf1c7e 19 (unreleased) landed
-
Add pg_get_role_ddl() function
- 76e514ebb4b5 19 (unreleased) landed
-
Add pg_get_tablespace_ddl() function
- b99fd9fd7f36 19 (unreleased) landed