Re: Retail DDL

From: Hannu Krosing <hannuk(at)google(dot)com>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Retail DDL
Date: 2025-07-25 08:48:46
Message-ID: CAMT0RQRP42pd7dD31PSxMJhZEZhnqb15rYDEb0NcDO32ELb3ug@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

A related improvement would be to also support

CREATE EXTENSION psql;

To make at least the `\d ...` commands available to any client

And while we are at it, why not also

CREATE EXTENSION pgbench;

To make the fancy random distribution functions (at least) from
pgbench available from inside the database.

On Fri, Jul 25, 2025 at 10:43 AM Hannu Krosing <hannuk(at)google(dot)com> wrote:
>
> I have been thinking of this from a little different direction. We
> already have all the needed functionality in pg_dump so why not just
> have an option to do
>
> CREATE EXTENSION pg_dump;
>
> Which would wrap and expose whatever the current version of pg_dump is doing.
>
> It still would need to resolve the difficult question of naming
> things, but otherways it looks like just a certain amount of
> mechanical work.
>
> We could even have just one set of functions with a few possible argument types
>
> pg_dump(object oid, options text);
> pg_dump(object text, options text);
>
> ---
> Hannu
>
>
>
>
>
>
>
>
>
> On Fri, Jul 25, 2025 at 10:35 AM Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
> >
> > On 2025-Jul-24, Andrew Dunstan wrote:
> >
> > > Obviously we already have some functions for things like views and
> > > triggers, but most notably we don't have one for tables, something users
> > > have long complained about. I have been trying to think of a reasonable
> > > interface for a single function, where we would pass in, say, a catalog oid
> > > plus an object oid, and maybe some optional extra arguments.
> >
> > Reproducing a table might need multiple commands. Do you intend to
> > return a single string containing multiple semicolon-separated commands,
> > or are you thinking in a RETURNS SETOF where each row contains a single
> > command?
> >
> > What about schema-qualification needed for elements in the commands? We
> > have the option to schema-qualify everything, _or_ to depend on whether
> > the schemas are in search_path, _or_ to schema-qualify nothing (which
> > gives the user the chance to recreate in any schema by changing
> > search_path).
> >
> >
> > > That seems a bit fragile, though. The alternative is that we have a
> > > separate function for each object type, e.g. pg_get_{objecttype}_ddl.
> > > I'm kinda leaning that way, but I'd like some sort of consensus before
> > > any work gets done.
> >
> > It looks like the discussion is leaning this way too. I think it's
> > a reasonable choice.
> >
> > --
> > Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
> >
> >

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2025-07-25 08:57:29 Re: Custom pgstat support performance regression for simple queries
Previous Message vignesh C 2025-07-25 08:46:06 Re: 024_add_drop_pub.pl might fail due to deadlock