Re: Retail DDL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: Kirill Reshke <reshkekirill(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Ziga <ziga(at)ljudmila(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Retail DDL
Date: 2025-08-16 14:22:50
Message-ID: 758258.1755354170@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre(at)kurilemu(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Marthin Laubscher 2025-08-16 16:04:59 Re: About Custom Aggregates, C Extensions and Memory
Previous Message Greg Burd 2025-08-16 14:00:09 Re: `pg_ctl init` crashes when run concurrently; semget(2) suspected