On Fri, Sep 11, 2026 at 08:24:50AM -0400, Robert Haas wrote: > On Fri, Sep 11, 2026 at 1:27 AM Noah Misch <[email protected]> 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/[email protected]
