| From: | Marcos Pegoraro <marcos(at)f10(dot)com(dot)br> |
|---|---|
| To: | Akshay Joshi <akshay(dot)joshi(at)enterprisedb(dot)com> |
| Cc: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH] Add pg_get_table_ddl() to reconstruct CREATE TABLE statements |
| Date: | 2026-06-22 14:54:38 |
| Message-ID: | CAB-JLwYLFJ9aroD0V9VWWWfrMQFQVRv4dZgJKmCFEs+JMoNQ7g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Em seg., 22 de jun. de 2026 às 03:27, Akshay Joshi <
akshay(dot)joshi(at)enterprisedb(dot)com> escreveu:
> The documentation paragraph for `includes_foreign_keys` now directs users
> to `only_foreign_keys` as the intended second pass. Regression coverage
> adds three cases: the FK-only emission for your cons example, the zero-row
> result for a table without FKs, and the error path.
>
>>
I still think this model of only having options for foreign keys is
incomplete, maybe wrong.
Imagine then cloning a schema from a publication server to be executed on a
subscription server. So I don't want any other constraints besides the
primary key, for example. The way you implemented it is not possible.
Furthermore having only_foreign_keys and includes_foreign_keys seems
confuse.
regards
Marcos
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2026-06-22 15:22:01 | Re: Proposal: Conflict log history table for Logical Replication |
| Previous Message | Renaud Métrich | 2026-06-22 14:53:09 | Re: [PATCH v3] Add ssl_cert_files/ssl_key_files for multi-certificate support |