Re: pg_get_*_ddl() needs a redesign

On Fri, Sep 11, 2026 at 08:24:50AM -0400, Robert Haas wrote:
> On Fri, Sep 11, 2026 at 1:27 AM Noah Misch <noah(at)leadboat(dot)com> wrote:
> > > 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 defects are the reason not to ship this implementation. One of those
> > defects, the inability to restore in dependency order, cannot be fixed without
> > redesigning the current SQL-facing API. That is the reason not to ship this
> > design. See my original post of this thread for details.
>
> I saw that, but that seems like you're questioning the feature's
> choice of scope as much as its actual merits.

That is not the case.

> I suppose the idea was
> that this feature is for getting the definition of an individual
> object for possible cloning into this database or some other where the
> prerequisites are already present. If the feature had the intention of
> allowing for full-database restoration and failed to do so, that's a
> code defect. Otherwise, it isn't.

The first discussion linked from the 76e514e commit message, [1], described
the "main use case" as "dumping role definitions for migration or backup
purposes without needing pg_dumpall". My review findings are about failures
that arise when using the feature as part of a migration.

[1] https://postgr.es/m/4c5f895e-3281-48f8-b943-9228b7da6471@gmail.com