>Original
>From: Jim Jones <[email protected]>
>Date: 2026-07-23 19:51
>To: ZizhuanLiu X-MAN <[email protected]>, matheusssilv97
><[email protected]>, Chao Li <[email protected]>, masao.fujii
><[email protected]>, david.g.johnston <[email protected]>, tgl
><[email protected]>, huseyin.d3r <[email protected]>
>Cc: pgsql-hackers <[email protected]>
>Subject: Re: COMMENTS are not being copied in CREATE TABLE LIKE
>These are good points, but I'd argue that excluding multiple tables from
>this feature would be hard to justify. Some of these points can be made
>to column comments as well -- we cannot guarantee their semantics in the
>new table, and yet we allow them to be copied.
>
>postgres=# CREATE TABLE t1 (a int);
>COMMENT ON COLUMN t1.a IS 'foo';
>CREATE TABLE t2 (b int);
>COMMENT ON COLUMN t2.b IS 'bar';
>
>CREATE TABLE tm (
> LIKE t1 INCLUDING COMMENTS,
> LIKE t2 INCLUDING COMMENTS
>);
>CREATE TABLE
>COMMENT
>CREATE TABLE
>COMMENT
>CREATE TABLE
>postgres=# SELECT
> col_description('tm'::regclass::oid, 1),
> col_description('tm'::regclass::oid, 2);
> col_description | col_description
>-----------------+-----------------
> foo | bar
>(1 row)
>
>In this case is up to user to either make sure the column comments are
>"transferable" or to correct them in the target table -- which is also
>my case on including the table comments.
>
>I'm not totally against dropping comments for multiple tables, but I
>want to make sure our arguments against having them make sense. If we
>conclude that it's impractical to concatenate table comments we should
>also consider the option of withdrawing the patch -- it's not like I'm
>terribly in love with it :)
>
>Thanks for the input!
>
>Best, Jim
Hi, Jim, everyone
Thanks for all your feedback, discussion and reminders.
After further consideration, I would like to clarify that I am only sharing my
personal perspective here, with no intention of pushing for any specific
implementation or insisting on my preference.
I have reviewed the relevant syntax and parsing rules:
```SQL
{ INCLUDING | EXCLUDING }
{ COMMENTS | COMPRESSION | CONSTRAINTS | DEFAULTS | GENERATED | IDENTITY |
INDEXES | STATISTICS | STORAGE | ALL }
```SQL
With the existing implementation, any object enabled via these clauses is
copied strictly one-to-one alongside the source objects. The command never
performs additional logic such as merging content or pruning items
automatically.
This leaves three general user workflows for any single attribute type XXX:
1. All instances of XXX fit the use case perfectly: use `INCLUDING XXX` with no
post-copy modifications required.
2. Most items of XXX are suitable: copy via `INCLUDING XXX`, then apply minor
manual adjustments afterward.
3. Only a small subset of XXX items are needed: skip copying entirely with
`EXCLUDING XXX`, with optional follow-up tweaks.
Extending this logic to the full set of attributes covered by `ALL`:
1. Every attribute works as expected: use `INCLUDING ALL` with zero follow-up
changes.
2. Most attributes are applicable: either copy everything with `INCLUDING ALL`
and tweak afterward,
or use `INCLUDING ALL` paired with `EXCLUDING XXX/YYY/ZZZ...` to exclude
unwanted categories.
3. Only a minority of attributes are required: opt for `EXCLUDING ALL`, then
explicitly list needed items
via `INCLUDING XXX/YYY/ZZZ...`.
The current syntax design covering `INCLUDING`, `EXCLUDING`, and `ALL` already
offers adequate
flexibility for users to make top-level copy decisions.
One-to-one copying works reliably when exactly one source table is used.
Multi-table scenarios constitute the only exceptional case where the command’s
behavior diverges
from single-table usage. If we can resolve the merging logic properly, I
believe merging comments
would be a reasonable approach. I do not think introducing brand-new dedicated
syntax options is
necessary for this scenario. At this stage, I have not come up with a more
elegant alternative solution.
regards,
--
ZizhuanLiu (X-MAN)
[email protected]
