Re: pg_get_*_ddl() needs a redesign

On Wed, Sep 09, 2026 at 03:12:26PM -0400, Andrew Dunstan wrote:
> 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.

Going forward, feel free to add me to the To: line of a mailing list post and
explicitly ask me for my guess about the project's overall prognosis, likely
ways of failing, etc. My guess may be brief and/or wrong, but I'll provide
one.

When it's four months after feature freeze and I find non-subtle, unreported
defects in the feature, the development process wasn't adequate for the
subject matter. To be transparent, observing this outcome changed my view of
code duplication. Duplication was always a smell, but it seemed like a
plausible compromise tactic in 2025. Now I find the duplication gave wrong
code too much place to hide.

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

I'm prepared to accept that outcome.