Re: Retail DDL

On Sat, Aug 16, 2025 at 4:23 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
> > On 2025-Aug-16, Kirill Reshke wrote:
> >> After putting some more thought into it, maybe we can implement the
> >> whole thing as contrib extension? This would be the most Postgres-y
> >> way to me.
>
> > If we do that, then core tools such as psql or pg_dump can never depend
> > on them.  -1 from me.
>
> pg_dump will never depend on any such thing anyway.  It has too many
> special-purpose requirements, like needing to split up object
> definitions in particular ways,

That can be handy for the use of get_ddl_function as well.

I remember creating a view, then creating a set-returning function
returning that view and then redefining the view to be a select from
that function.

pg_dump did split this up in a nicel dumpable way, though a little
different than the original set of DDL.

We definitely want our server functions to be able to also cope with
circularities.

> cope with very old server versions,

This is never needed here, as we only show DDL for our own version.

> etc etc.  Insisting that this feature support pg_dump is a good way
> of making sure that nothing useful will emerge at all.
>
> Maybe we could replace (some of) psql's describe.c logic with
> server-side code, but I'm skeptical that there'd be much win
> there either.

But we already have some trickier parts in the server, like getting
view and function definitions, foreign key definitions, possibly more.

> So I don't really buy Álvaro's argument above.  It'd be better
> to design to some concrete requirement that isn't either of
> those.  Unfortunately, it's not clear to me that anyone has
> a concrete use-case in mind that isn't either of those.

IMHO pg_dump is actually a good model for "concrete requirements"  as
any requirements I can think of - and have needed in th epast - are
some subset of pg_dump --schema-only