>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
I have checked Db2’s syntax design. Db2’s LIKE syntax is intended to copy
columns
only from a single source object, which may be a table, view or nickname. This
matches
our discussion perfectly: single-table usage works smoothly, but it is
difficult to implement
elegant comment copying when multiple source tables are involved.
```Db2
>>-CREATE TABLE--table-name------------------------------------->
>--+-| element-list |----------------------------+--●----------->
+-OF--type-name1--+-------------------------+-+
| '-| typed-table-options |-' |
+-LIKE--+-table-name1-+--+------------------+-+
| +-view-name---+ '-| copy-options |-' |
| '-nickname-----' |
+-| as-result-table |--+------------------+---+
| '-| copy-options |-' |
+-| materialized-query-definition |-----------+
'-| staging-table-definition |----------------'
......
......
copy-options
|--●--+---------------------------------------------+--●---------------->
| .-COLUMN-. |
'-+-INCLUDING-+--+-----------+--DEFAULTS-'
'-EXCLUDING-'
.-COLUMN ATTRIBUTES-.
.-EXCLUDING IDENTITY--+-------------------------+-.
>--+-------------------------------------------------------+--●-------------|
| .-COLUMN ATTRIBUTES-. |
'-INCLUDING IDENTITY--+-------------------------+--'
```Db2
I suspect PostgreSQL’s CREATE TABLE LIKE was also originally intended to copy
metadata
from just one source table, though I found no archived mailing list records to
verify this
original design purpose. Even so, PostgreSQL’s syntax and implementation allow
users to
specify multiple source tables.
I think multi-table support was added mainly to aggregate columns from
different tables,
since most options under `INCLUDING`/`EXCLUDING` govern column-level
attributes.
This leads me to wonder why table comment copying was never implemented.
It is probable that developers chose to omit multi-table table comment copying
to
enable merging columns from several source tables. Even so, copying table
comments
when there is only one source table would be a valuable improvement.
Overall, PostgreSQL supports many more copyable objects and attributes than Db2.
regards,
--
ZizhuanLiu (X-MAN)
[email protected]
