=?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, cope with very old server versions,
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.
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.
regards, tom lane
