Re: COMMENTS are not being copied in CREATE TABLE LIKE

From: ZizhuanLiu X-MAN <44973863(at)qq(dot)com>
To: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, matheusssilv97 <matheusssilv97(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, masao(dot)fujii <masao(dot)fujii(at)gmail(dot)com>, david(dot)g(dot)johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, tgl <tgl(at)sss(dot)pgh(dot)pa(dot)us>, huseyin(dot)d3r <huseyin(dot)d3r(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, 我自己的邮箱 <44973863(at)qq(dot)com>
Subject: Re: COMMENTS are not being copied in CREATE TABLE LIKE
Date: 2026-07-24 07:07:07
Message-ID: tencent_5E36175A9C098B6F01CB226AACC64AF88207@qq.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>Original
>From: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
>Date: 2026-07-23 19:51
>To: ZizhuanLiu X-MAN <44973863(at)qq(dot)com>, matheusssilv97 <matheusssilv97(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, masao.fujii <masao(dot)fujii(at)gmail(dot)com>, david.g.johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, tgl <tgl(at)sss(dot)pgh(dot)pa(dot)us>, huseyin.d3r <huseyin(dot)d3r(at)gmail(dot)com>
>Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
>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) 
44973863(at)qq(dot)com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2026-07-24 07:10:35 Re: DOCS: Describe some missing parameters on CREATE/ALTER PUBLICATION pages
Previous Message Fujii Masao 2026-07-24 06:53:27 Re: Incorrect check in 037_except.pl?