Re: Retail DDL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Retail DDL
Date: 2025-07-24 21:36:10
Message-ID: 1748518.1753392970@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> .... 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. 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.

I'm good with pg_get_{objecttype}_ddl. The reason I like it is that
that sets expectations for what the function can do, and we don't
have to immediately cover every object type there is in order to not
have a function with unexpected restrictions.

A small advantage is that, for object types having a reg* pseudotype,
we can declare the function as (say)

pg_get_table_ddl(regclass)

and that means this will work with no additional decoration:

select pg_get_table_ddl('mytable');

Nearby, Isaac suggested sort of the reverse of that, where
you'd have to write

select pg_get_ddl('mytable'::regclass);

but I don't see any great advantages in that --- and it can't scale
to object types that lack a reg* type.

regards, tom lane

In response to

  • Retail DDL at 2025-07-24 20:26:04 from Andrew Dunstan

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Cramer 2025-07-24 21:39:14 Re: More protocol.h replacements this time into walsender.c
Previous Message KAZAR Ayoub 2025-07-24 21:25:51 Re: Experimenting with hash join prefetch