Re: pg_get_*_ddl() needs a redesign

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. 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. If the feature could reasonably have
been designed in such a way that it would allow for full-database
restoration but was not actually designed in such a way, that's a
design defect. It's not obvious to me that this is the case, but it
might be. If there's no reasonable way to make a feature of this type
suitable for that use case, this isn't a defect at all, just code that
does something that you may not find entirely worthwhile. Regardless,
I'm not saying that you have to like this feature -- I don't think
it's great either, although it seems I dislike it less than you -- but
I think fairness demands that we not label as code defects issues that
are properly categorized otherwise.

--
Robert Haas