Re: pg_get_*_ddl() needs a redesign

On 2026-09-09 We 1:34 PM, Tom Lane wrote:
> Noah Misch<noah(at)leadboat(dot)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