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<[email protected]> 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.
