Re: pg_get_*_ddl() needs a redesign

On Thu, Sep 10, 2026 at 12:00 AM Noah Misch <noah(at)leadboat(dot)com> wrote:
> 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.

I don't think this is how this mailing list works. The volume is
overwhelming for me, too, but patch authors aren't obliged to cc
anyone specifially.

> 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 think we would do well to confine all of our present conversations,
insofar as it is possible to do so, to whether any given feature
contains defects incompatible with shipping it. The desirability of
this particular feature is, as Andrew says, something that would have
been better litigated six or more months ago. Granted, we're all
overwhelmed, and that makes it more understandable that people who had
concerns about desirability did not raise them at the time, but we
will not succeed in producing awesome software by forcing last-minute
reverts because we've changed our mind about whether the feature is a
good idea in principle. There's more than enough to revert on the
basis of whatever is broken in practice.

That said, if this is coming out of v19 anyway, then IMHO it is fair
game to reopen the question of whether we want it in v20. But if we're
going to do that, we should hash that out now rather than in six
months from now or twelve months from now. Personally, I have mixed
feelings about this feature. On the one hand, I am sure it will get
some use, and I have wanted it myself. On the other hand, it will get
far less use, and far less testing, than the equivalent code in
pg_dump, so it's more likely to have bugs now and in the future, and
the fact that there's no reasonable way (at least, not that I can see)
to handle version skew within a facility like this is a major
disadvantage vs. pg_dump. Nevertheless, on balance, I'm unconvinced
that there's sufficient reason to categorically block a
sufficiently-well-implemented feature of this type. But not even the
most desirable feature should remain in tree if the implementation
isn't of sufficient quality.

--
Robert Haas