On Sat, Aug 16, 2025 at 4:23 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > =?utf-8?Q?=C3=81lvaro?= Herrera <alvhe...@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
