Re: pg_get_*_ddl() needs a redesign - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: pg_get_*_ddl() needs a redesign
Date
Msg-id ccd76a86-51c0-4395-b6b2-2e7214c2fbf2@dunslane.net
Whole thread
In response to pg_get_*_ddl() needs a redesign  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers


On 2026-09-09 We 1:34 PM, Tom Lane wrote:
Noah Misch <noah@leadboat.com> writes:
I want to clarify one thing before you spend much time on fixes.  I don't see
"fixes" addressing this thread as a whole, unless you plan to dispute the
premise that the feature needs a redesign.  In other words, I think the thread
outcome should be one of these:
- My review erred in determining that the feature needs a redesign.  The  design is sound and should proceed, possibly with some fixes.
- Revert the feature.
FWIW, I agree with Noah's point that having two independent
implementations of SQL reverse compilation is not really a place
we want to be: it will be a major PITA for future development.

Unfortunately, I see no practical way to have pg_dump share code with
the backend for most of this stuff; not least because pg_dump has to
support dumping from old backends that won't have any such feature.
So we either swallow that duplication or decide that we're never
going to support this in the backend.  Neither choice is palatable,
but I don't think I want to be forced into the duplicative approach
when we've not explored other alternatives (such as refactoring
pg_dump to expose its internal logic in some way).
			


I first raised the idea of these functions on the mailing list in July 2025, although the idea was much older. [1] Among other things, you (Tom) said [2]:

Insisting that this feature support pg_dump is a good way
of making sure that nothing useful will emerge at all.
Concrete patches began to appear around October and November 2025. I don't recall anyone coming along and saying "No, we don't want to do that." After they were committed there were various comments on the way they were done, and I addressed them.  Now, months later, we are more or less told that this whole enterprise has been misguided from the start. Is it any wonder that people often find the process of contributing to Postgres discouraging? And that would include people who have been working on more important members of this set for release 20, particularly the one that most people want, namely pg_get_table_ddl() that Akshay has been working on. I don't feel badly for myself, but I do feel badly for the contributors.

I believe reverting now almost certainly means this proposal or anything like it is probably dead for the foreseeable future. 

To me it is beyond stupid that a postgresql server doesn't have enough introspection to be able to produce the DDL for its own objects. Telling people that they have to call pg_dump/pg_dumpall to generate the DDL programmatically is awful. So, do I think this is worth the possible maintenance burden? Yes. I might take a suggestion of "needs redesign" more seriously if there had been a hint of what that might look like. But without that it looks to me like a way of saying "I don't like the feature or think we need it."

cheers

andrew


[1]  https://postgr.es/m/945db7c5-be75-45bf-b55b-cb1e56f2e3e9@dunslane.net

[2]  https://postgr.es/m/758258.1755354170@sss.pgh.pa.us


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Report index currently being vacuumed in pg_stat_progress_vacuum
Next
From: Kirill Reshke
Date:
Subject: Re: postgres_fdw: Use COPY to speed up batch inserts