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: Matheus Alcantara <matheusssilv97(at)gmail(dot)com>, 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-18 14:03:59
Message-ID: tencent_D0A4135EDF6E96A0D4478DABF0656D6DB408@qq.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>Hi,
>
>While reviewing another patch[1] I saw that COMMENTS on tables are being
>ignored in CREATE TABLE LIKE:
>.....
>Thoughts?
>
>Best, Jim
>
>1 -
>https://www.postgresql.org/message-id/flat/DG7Y34A6VBEG.76L7K1OML5DI%40gmail.com

Hi everyone,

I would like to share my understanding of common use cases for `CREATE TABLE LIKE`
alongside some related thoughts on copying table comments.

1. When cloning a table together with its associated objects and comments for an
entirely separate business purpose:
1.1 If the user has no special requirements for the comment on the newly created table,
whether the table-level comment is copied or not will make no practical difference to them.
1.2 If the user does need a customized comment for the new table, they will manually run a
`COMMENT ON TABLE` statement to rewrite the description even under the current behavior
that does not copy table comments. Therefore the final outcome remains unaffected regardless
of whether table comments are inherited via `CREATE TABLE LIKE`.

2. If the cloned table is intended to replace the original source table, enabling automatic copy of
the table comment will bring obvious convenience and benefits.

3. In cases where multiple source tables are referenced in one `LIKE` clause, I suggest skipping table
comment copying entirely. Concatenating multiple disparate table comments would result in bloated
and confusing text that fails to accurately describe the intended purpose of the combined new table.

4. As for table ownership and access privileges, these attributes should follow the default rules applied
during standard table creation rather than being copied one-to-one from the source table. We can
draw an analogy to the `cp` command in operating systems: file and directory ownership, group
assignments and access permissions are determined by the system umask environment variable instead
of an exact duplicate of the source file’s permission settings.

5. This aligns with an earlier suggestion from the mailing list thread linked below:
https://www.postgresql.org/message-id/flat/20090907114058(dot)C855(dot)52131E4D(at)oss(dot)ntt(dot)co(dot)jp
> I realize that might involve a bit
> more code, but I think I'd feel happier if we cloned all the comments we
> reasonably could from the outset.”

From my perspective, adding support to copy table-level comments carries no obvious negative side effects.

Thanks for your time and discussion.

regards,
--
ZizhuanLiu (X-MAN) 
44973863(at)qq(dot)com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2026-07-18 14:40:13 Re: sequencesync worker race with REFRESH SEQUENCES
Previous Message Thom Brown 2026-07-18 07:56:59 Re: [PATCH] Rename "getdatabaseencoding()" to "pg_database_encoding()", and document