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
