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.
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/[email protected]
[2] https://postgr.es/m/[email protected]
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
