From: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
---|---|
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-25 08:34:57 |
Message-ID: | 202507250834.miv6ngojgak3@alvherre.pgsql |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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/
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2025-07-25 08:42:50 | Re: Allow ON CONFLICT DO UPDATE to return EXCLUDED values |
Previous Message | shveta malik | 2025-07-25 08:25:03 | Re: Logical replication launcher did not automatically restart when got SIGKILL |