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
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 |