Re: Retail DDL

From: Hannu Krosing <hannuk(at)google(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Álvaro Herrera <alvherre(at)kurilemu(dot)de>, 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-19 07:27:43
Message-ID: CAMT0RQRc=Nn9Mc9NiR=mrEcCReEkssDzb-NQ=1DyO+Z4SHPoSw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Aug 16, 2025 at 4:23 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> =?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,

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2025-08-19 07:31:27 Re: New commitfest app release on August 19th
Previous Message Michael Paquier 2025-08-19 07:21:39 Re: New commitfest app release on August 19th