Re: pg_get_*_ddl() needs a redesign

On Fri, Sep 11, 2026 at 10:23 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > 2. pg_dump just calls the source server's DDL-reconstruction functions
> > and doesn't have to worry about version skew.
>
> Isn't the problem with that that we occasionally need to adapt the syntax
> between versions to some degree? I think it has become less common, but I'm a
> bit sceptical that it's wise to decide we won't ever again need that...

+1.

> > (B) pg_dump slices and dices the data in ways that don't necessarily
> > make sense for standalone usage. For example it doesn't want to
> > mention a primary key when creating a table, rather it wants to add
> > that constraint (and build the index) after loading data.
>
> Yep, that seems nontrivial.

The kind of scenario Tom mentions here is exactly why I'm unwilling to
take Noah's criticisms purely at face value. Dealing with dependencies
means splitting up the creation of single objects into multiple DDL
commands in weird ways. But if you just want the definition of one
single object expressed in the most straightforward way, you are going
to want the primary key as part of the object definition, not a
separate, broken-out statement. There are use cases for both things.
If we judge the facility that was built here as a substitute for
pg_dump, it's fatally flawed and should come straight out of the tree
and be deposited directly and permanently into the circular file,
which seems to be what Noah wants. But if we judge it as having a
separate purpose, then the question is how well it serves that
purpose. And the phrase Tom uses, "standalone usage," is at least
sketch of a purpose where dependency handling is irrelevant and
perhaps even undesirable.

--
Robert Haas