| 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
| 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? |