PostgreSQL drops role DDL functions from version 19

PostgreSQL will pull the new pg_get_role_ddl() family of functions from the version 19 release after a late review concluded the design cannot support its stated purpose of role migration and backup without pg_dumpall.

Noah Misch reported that the functions omit passwords even though pg_dumpall can emit stored password hashes, bundle database-specific ALTER ROLE settings with CREATE ROLE in a way that breaks restore onto an empty cluster, and reimplement SQL reverse compilation already maintained inside pg_dump. Those flaws, he argued, cannot be patched without redesigning the SQL-facing API.

Andrew Dunstan, who committed the feature, said he had working but invasive fixes for permissions and testing yet lacked time to polish them before release. He proposed reverting for version 19 while continuing work on the master branch.

That plan opened a wider question of whether the feature should return at all. Tom Lane warned that two independent reverse-compilation paths would become a lasting maintenance burden, with no practical way for pg_dump to call server-side helpers given the need to dump older servers, bulk-gather performance, and the way pg_dump deliberately splits object creation across multiple statements. Robert Haas voiced mixed feelings: the functions would see some use, yet far less testing than pg_dump, raising the chance of silent breakage when new DDL options appear. Andres Freund suggested separating metadata collection from SQL generation so both sides could share a library, but that remains exploratory.

Lane concluded that if the facility cannot serve pg_dump's needs, it is not useful enough to justify the duplicated load and should be discarded. Version 19 will ship without the current implementation; any redesigned approach is left for a later cycle.