Request a Demo
Home   >   mailing lists

Re: [PATCH] Add pg_get_table_ddl() to reconstruct CREATE TABLE statements - Mailing list pgsql-hackers

From Akshay Joshi
Subject Re: [PATCH] Add pg_get_table_ddl() to reconstruct CREATE TABLE statements
Date
Msg-id CANxoLDdEBYzKfj3NGrP5PjoTa-eCViWPkFR-sXLq4bUnbokyPA@mail.gmail.com
Whole thread
Responses Re: [PATCH] Add pg_get_table_ddl() to reconstruct CREATE TABLE statements
List pgsql-hackers
Tree view
All,

A quick note on a design change I made in the pg_get_table_ddl option surface.

The earlier draft exposed one boolean option per sub-object kind: include_indexes, include_primary_key, include_check, include_foreign_keys, include_rules, include_statistics, include_rls, include_replica_identity, include_partitions, and so on. Every new kind we wanted to gate (triggers, policies, exclusion constraints…) meant another option name. Callers wanting "everything except FKs" had to flip nine flags, and the include/exclude polarity was not symmetric: to drop one item, you toggled one flag, but to keep only one item, you toggled all the others. 

I have replaced those with two options:
  - include — comma-separated list of kinds; emit only the listed ones. 
  - exclude — comma-separated list of kinds; emit everything except the listed ones.

Vocabulary: table, indexes, primary_key, unique, check, foreign_keys, exclusion, rules, statistics, triggers, policies, rls, replica_identity, partitions.
NOT NULL is intentionally omitted from the vocabulary; it's always emitted to avoid silently producing schemas that accept NULLs when the source would have rejected them. 

The v10 patch is ready for review.

On Tue, Jun 23, 2026 at 2:52 PM Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:


On Tue, Jun 23, 2026 at 12:51 PM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote:
At Mon, 22 Jun 2026 18:10:53 +0530, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote in
> The v9 patch is ready for review.

I have not looked closely at the DDL generation logic itself, but I
have a few comments on how pg_get_table_ddl handles its options.

Since pg_get_table_ddl_internal() appears to copy these values into
TableDdlContext almost immediately, I wonder whether TableDdlContext
could be initialized by the caller instead.

Using positional boolean arguments is probably fine when there are
only a handful of options, but with around fifteen of them the current
approach seems somewhat error-prone.

It might also be clearer to initialize the default values first, and
then override only the fields corresponding to explicitly specified
options, rather than folding the default handling and option lookup
into the same expression.

I assume that changing the implementation model, as I mentioned in my other email, will solve this problem as well. We can drop the entire includes_* family and only_foreign_keys, and replace them with two mutually exclusive variadic keys:
include => 'kind1,kind2,...' — emit only these kinds
exclude => 'kind1,kind2,...' — emit everything except these kinds

Regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center
Attachment

pgsql-hackers by date:

Previous
From: Andrei Lepikhov
Date:
Subject: Re: Logging parallel worker draught
Next
From: Benoit Lobréau
Date:
Subject: Re: Logging parallel worker draught