COMMENTS are not being copied in CREATE TABLE LIKE

Hi, thanks for checking this.

On Thu Feb 12, 2026 at 7:11 AM -03, Jim Jones wrote:

Hi,

While reviewing another patch[1] I saw that COMMENTS on tables are being
ignored in CREATE TABLE LIKE:

psql (18.1 (Debian 18.1-1.pgdg13+2))
Type "help" for help.

postgres=# \pset null '(null)'
Null display is "(null)".
postgres=# CREATE TABLE t1 (id int, name text);
COMMENT ON TABLE t1 IS 'table comment';
CREATE TABLE t2 (LIKE t1 INCLUDING ALL);
CREATE TABLE t3 (LIKE t1 INCLUDING COMMENTS);

SELECT
obj_description('t1'::regclass, 'pg_class') AS t1_comment,
obj_description('t2'::regclass, 'pg_class') AS t2_comment,
obj_description('t3'::regclass, 'pg_class') AS t3_comment;
CREATE TABLE
COMMENT
CREATE TABLE
CREATE TABLE
t1_comment | t2_comment | t3_comment
---------------+------------+------------
table comment | (null) | (null)
(1 row)

v1 attached attempts to fix it by expanding expandTableLikeClause() to
retrieve and copy the table-level comment when the INCLUDING COMMENTS
[ALL] option is specified:

The patch fix the issue and it seems correct to me.

This bug seems to also happen on 14.20:
postgres=# select version();
version
------------------------------------------------------------------------------------------------------------------------------
PostgreSQL 14.20 (Homebrew) on aarch64-apple-darwin24.6.0, compiled by Apple clang version 17.0.0 (clang-1700.4.4.1), 64-bit
(1 row)

postgres=# CREATE TABLE t(a int, b text);
CREATE TABLE
postgres=# COMMENT ON TABLE t IS 'foo';
COMMENT
postgres=# CREATE TABLE t2(LIKE t INCLUDING ALL);
CREATE TABLE
postgres=# SELECT obj_description('t'::regclass, 'pg_class') as t_comment, obj_description('t2'::regclass, 'pg_class') AS t2_comment;
t_comment | t2_comment
-----------+------------
foo |
(1 row)

So I think that we need to backport.

--
Matheus Alcantara
EDB: https://www.enterprisedb.com

On Thu, Feb 12, 2026 at 11:36 PM Matheus Alcantara
<matheusssilv97@gmail.com> wrote:

Hi, thanks for checking this.

On Thu Feb 12, 2026 at 7:11 AM -03, Jim Jones wrote:

Hi,

While reviewing another patch[1] I saw that COMMENTS on tables are being
ignored in CREATE TABLE LIKE:

psql (18.1 (Debian 18.1-1.pgdg13+2))
Type "help" for help.

postgres=# \pset null '(null)'
Null display is "(null)".
postgres=# CREATE TABLE t1 (id int, name text);
COMMENT ON TABLE t1 IS 'table comment';
CREATE TABLE t2 (LIKE t1 INCLUDING ALL);
CREATE TABLE t3 (LIKE t1 INCLUDING COMMENTS);

SELECT
obj_description('t1'::regclass, 'pg_class') AS t1_comment,
obj_description('t2'::regclass, 'pg_class') AS t2_comment,
obj_description('t3'::regclass, 'pg_class') AS t3_comment;
CREATE TABLE
COMMENT
CREATE TABLE
CREATE TABLE
t1_comment | t2_comment | t3_comment
---------------+------------+------------
table comment | (null) | (null)
(1 row)

v1 attached attempts to fix it by expanding expandTableLikeClause() to
retrieve and copy the table-level comment when the INCLUDING COMMENTS
[ALL] option is specified:

The patch fix the issue and it seems correct to me.

This bug seems to also happen on 14.20:
postgres=# select version();
version
------------------------------------------------------------------------------------------------------------------------------
PostgreSQL 14.20 (Homebrew) on aarch64-apple-darwin24.6.0, compiled by Apple clang version 17.0.0 (clang-1700.4.4.1), 64-bit
(1 row)

postgres=# CREATE TABLE t(a int, b text);
CREATE TABLE
postgres=# COMMENT ON TABLE t IS 'foo';
COMMENT
postgres=# CREATE TABLE t2(LIKE t INCLUDING ALL);
CREATE TABLE
postgres=# SELECT obj_description('t'::regclass, 'pg_class') as t_comment, obj_description('t2'::regclass, 'pg_class') AS t2_comment;
t_comment | t2_comment
-----------+------------
foo |
(1 row)

So I think that we need to backport.

The documentation [1]https://www.postgresql.org/docs/devel/sql-createtable.html#SQL-CREATETABLE-PARMS-LIKE-OPT-COMMENTS states that INCLUDING COMMENTS copies comments for
the copied columns, constraints, and indexes. It does not mention copying
comments on the table itself. Therefore, not copying table comments with
INCLUDING COMMENTS does not appear to be a bug. That is, the proposed patch
seems more like an improvement than a bug fix.

Regards,

[1]: https://www.postgresql.org/docs/devel/sql-createtable.html#SQL-CREATETABLE-PARMS-LIKE-OPT-COMMENTS
https://www.postgresql.org/docs/devel/sql-createtable.html#SQL-CREATETABLE-PARMS-LIKE-OPT-COMMENTS

--
Fujii Masao

On 12/02/2026 16:08, Fujii Masao wrote:

On Thu, Feb 12, 2026 at 11:36 PM Matheus Alcantara
<matheusssilv97@gmail.com> wrote:

The patch fix the issue and it seems correct to me.

Thanks for the review!

The documentation [1] states that INCLUDING COMMENTS copies comments for
the copied columns, constraints, and indexes. It does not mention copying
comments on the table itself. Therefore, not copying table comments with
INCLUDING COMMENTS does not appear to be a bug. That is, the proposed patch
seems more like an improvement than a bug fix.

Hmm, it seemed so obvious to me that I didn’t look more closely at the
documentation :) Although I struggle to see the rationale for not
copying a table’s comment in a CREATE TABLE LIKE ... INCLUDING COMMENTS
statement, I have to agree that the documentation is quite clear about
this limitation, and therefore it cannot really be considered a bug.
That said, it may well be worth considering for a future release.

What are your thoughts?

Thanks!

Best, Jim

On Thu Feb 12, 2026 at 12:33 PM -03, Jim Jones wrote:

On 12/02/2026 16:08, Fujii Masao wrote:

On Thu, Feb 12, 2026 at 11:36 PM Matheus Alcantara
<matheusssilv97@gmail.com> wrote:

The patch fix the issue and it seems correct to me.

Thanks for the review!

The documentation [1] states that INCLUDING COMMENTS copies comments for
the copied columns, constraints, and indexes. It does not mention copying
comments on the table itself. Therefore, not copying table comments with
INCLUDING COMMENTS does not appear to be a bug. That is, the proposed patch
seems more like an improvement than a bug fix.

Hmm, it seemed so obvious to me that I didn’t look more closely at the
documentation :)

Yeah, me too. I even checked if column comments was being created, but I
still assume that table comments should also be copied.

Although I struggle to see the rationale for not
copying a table’s comment in a CREATE TABLE LIKE ... INCLUDING COMMENTS
statement, I have to agree that the documentation is quite clear about
this limitation, and therefore it cannot really be considered a bug.
That said, it may well be worth considering for a future release.

What are your thoughts?

+1 for having this as a feature on a future release.

--
Matheus Alcantara
EDB: https://www.enterprisedb.com

On Feb 12, 2026, at 23:33, Jim Jones <jim.jones@uni-muenster.de> wrote:

On 12/02/2026 16:08, Fujii Masao wrote:

On Thu, Feb 12, 2026 at 11:36 PM Matheus Alcantara
<matheusssilv97@gmail.com> wrote:

The patch fix the issue and it seems correct to me.

Thanks for the review!

The documentation [1] states that INCLUDING COMMENTS copies comments for
the copied columns, constraints, and indexes. It does not mention copying
comments on the table itself. Therefore, not copying table comments with
INCLUDING COMMENTS does not appear to be a bug. That is, the proposed patch
seems more like an improvement than a bug fix.

Hmm, it seemed so obvious to me that I didn’t look more closely at the
documentation :) Although I struggle to see the rationale for not
copying a table’s comment in a CREATE TABLE LIKE ... INCLUDING COMMENTS
statement, I have to agree that the documentation is quite clear about
this limitation, and therefore it cannot really be considered a bug.
That said, it may well be worth considering for a future release.

What are your thoughts?

Thanks!

Best, Jim

I feel the current behavior is proper. When you create a table using LIKE, you are cloning the structure, not the identity. Just as you have to pick a new name for the table, you should provide a new comment that fits its specific purpose. If a comment is needed, the COMMENT ON command is already the straightforward way to handle that.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

On Fri, Feb 13, 2026 at 12:34 AM Jim Jones <jim.jones@uni-muenster.de> wrote:

On 12/02/2026 16:08, Fujii Masao wrote:

On Thu, Feb 12, 2026 at 11:36 PM Matheus Alcantara
<matheusssilv97@gmail.com> wrote:

The patch fix the issue and it seems correct to me.

Thanks for the review!

The documentation [1] states that INCLUDING COMMENTS copies comments for
the copied columns, constraints, and indexes. It does not mention copying
comments on the table itself. Therefore, not copying table comments with
INCLUDING COMMENTS does not appear to be a bug. That is, the proposed patch
seems more like an improvement than a bug fix.

Hmm, it seemed so obvious to me that I didn’t look more closely at the
documentation :) Although I struggle to see the rationale for not
copying a table’s comment in a CREATE TABLE LIKE ... INCLUDING COMMENTS
statement, I have to agree that the documentation is quite clear about
this limitation, and therefore it cannot really be considered a bug.
That said, it may well be worth considering for a future release.

What are your thoughts?

At first, I felt it would be more intuitive to copy the table comment as well.
However, on second thought, since LIKE can reference multiple tables,
copying table-level properties such as comments may not be well-defined.

For example, if two source tables each have a table comment and both are
specified in LIKE, which comment should be applied to the new table?

Regards,

--
Fujii Masao

On Thursday, February 12, 2026, Fujii Masao <masao.fujii@gmail.com> wrote:

For example, if two source tables each have a table comment and both are
specified in LIKE, which comment should be applied to the new table?

Both, with a new line between them.

David J.

Chao Li <li.evan.chao@gmail.com> writes:

On Feb 12, 2026, at 23:33, Jim Jones <jim.jones@uni-muenster.de> wrote:

On 12/02/2026 16:08, Fujii Masao wrote:

The documentation [1] states that INCLUDING COMMENTS copies comments for
the copied columns, constraints, and indexes. It does not mention copying
comments on the table itself. Therefore, not copying table comments with
INCLUDING COMMENTS does not appear to be a bug. That is, the proposed patch
seems more like an improvement than a bug fix.

Hmm, it seemed so obvious to me that I didn’t look more closely at the
documentation :) Although I struggle to see the rationale for not
copying a table’s comment in a CREATE TABLE LIKE ... INCLUDING COMMENTS
statement, I have to agree that the documentation is quite clear about
this limitation, and therefore it cannot really be considered a bug.
That said, it may well be worth considering for a future release.

I feel the current behavior is proper. When you create a table using
LIKE, you are cloning the structure, not the identity.

Yeah, I was about to make a similar comment. We do not for example
clone the ownership or permissions of the source table. Maybe there
is an argument for cloning the table-level comment but it's by no
means open-and-shut. So I think the current behavior is intentional
not an oversight. Might be good to go find the thread in which the
INCLUDING COMMENTS functionality was developed and see if there was
discussion.

(Speaking of which, I'm feeling very dubious about the nearby
proposal to invent LIKE INCLUDING POLICIES. It's hard to credit
that it makes sense to clone RLS policies while not cloning
table ownership and permissions. But I suppose I should raise
that point in that thread.)

regards, tom lane

Thanks everyone for the comments!

On 13/02/2026 05:30, Tom Lane wrote:

Chao Li <li.evan.chao@gmail.com> writes:

I feel the current behavior is proper. When you create a table using
LIKE, you are cloning the structure, not the identity.

The concern regarding identity is certainly a valid one, but in this
case I do not see how it applies. Copying the comment would not, IMHO,
transfer the identity of the source table (in a semantic sense), but
would instead merely indicate its provenance.

Yeah, I was about to make a similar comment. We do not for example
clone the ownership or permissions of the source table. Maybe there
is an argument for cloning the table-level comment but it's by no
means open-and-shut. So I think the current behavior is intentional
not an oversight. Might be good to go find the thread in which the
INCLUDING COMMENTS functionality was developed and see if there was
discussion.

I did a bit of digging in the mailing list and found this old thread[1]
where INCLUDING COMMENTS was introduced. I couldn't see anything related
to table-level comments there. Perhaps it was discussed elsewhere?

On 13/02/2026 05:13, Fujii Masao wrote:

For example, if two source tables each have a table comment and both are
specified in LIKE, which comment should be applied to the new table?

On 13/02/2026 05:22, David G. Johnston wrote:

Both, with a new line between them.

I supposed we could, as David mentioned, simply concatenate them. How it
should be done can be discussed, but a \n (or two) would IMO work just fine.

Example:

CREATE TABLE t1 (a int);
COMMENT ON TABLE t1 IS 'comment from table 1';
CREATE TABLE t2 (b int);
COMMENT ON TABLE t2 IS 'comment from table 2';
CREATE TABLE t3 (c int);
COMMENT ON TABLE t3 IS 'comment from table 3';

CREATE TABLE tm (
LIKE t1 INCLUDING COMMENTS,
LIKE t3 INCLUDING COMMENTS,
LIKE t2 INCLUDING COMMENTS
);

SELECT obj_description('tm'::regclass, 'pg_class') AS table_comment;
table_comment
----------------------
comment from table 1+
comment from table 3+
comment from table 2
(1 row)

Any thoughts on that?

Best, Jim

1 -
/messages/by-id/20090907114058.C855.52131E4D@oss.ntt.co.jp

Hi Jim,

I have a couple of concerns about the patch and I wanted to highlight the following cases.

1. Table comments tend to describe the purpose or context of a specific table (e.g. "staging table for pipeline X"), unlike column or constraint comments which describe the schema structure. Copying them by default may be wrong more often than it's right, since the new table almost certainly serves a different purpose than the source.
2. This changes the behavior of INCLUDING ALL, which many users rely on without thinking too carefully about what it pulls in. Silently copying a source table's comment (which might say something like "template — do not use directly") into every derived table could cause confusion in practice.

Neither of these is necessarily a blocker, but I think they're worth discussing before we commit to this as the default behavior under INCLUDING COMMENTS.

Before reviewing the patch for code quality and repo standards, I think we need to decide whether this behavior change is the right approach at all. My preference would be to keep table comments managed separately, given the situations above.

Hi Hüseyin

On 22/02/2026 09:05, Hüseyin Demir wrote:

1. Table comments tend to describe the purpose or context of a specific table (e.g. "staging table for pipeline X"), unlike column or constraint comments which describe the schema structure. Copying them by default may be wrong more often than it's right, since the new table almost certainly serves a different purpose than the source.

Good point. Comments may well lose their semantic value when placed in a
different context, but I'm not sure how it differs from column comments.
A column comment can also refer to a context (original table) that is no
longer applicable after cloning, specially when the CREATE TABLE LIKE
includes multiple tables.

2. This changes the behavior of INCLUDING ALL, which many users rely on without thinking too carefully about what it pulls in. Silently copying a source table's comment (which might say something like "template — do not use directly") into every derived table could cause confusion in practice.

It's also a valid concern - although I see it slightly differently. I we
take this line of reasoning too seriously, we might never be able to
expand CREATE TABLE LIKE, since the ALL keyword would be directly
affected (expanded) in the process. There are also other patches that
aim to expand CREATE TABLE LIKE, e.g. INCLUDING TRIGGERS[1]

Before reviewing the patch for code quality and repo standards, I think we need to decide whether this behavior change is the right approach at all. My preference would be to keep table comments managed separately, given the situations above.

Are you suggesting we should simply keep ignoring the table comments? Or
should we manage them differently?

Thanks for the comments. Much appreciated!

Best, Jim

1 - https://commitfest.postgresql.org/patch/6087/

Hi Jim,

Are you suggesting we should simply keep ignoring the table comments? Or
should we manage them differently?

Yes, because changing the behavior will lead to misinterpretations while
creating tables and tables derived from template ones will be presented
differently with respect to comments they have.

Such changes can cause unexpected different objects inside a database.
For example, any existing script using INCLUDING COMMENTS or INCLUDING ALL
will now copy the table comment where it didn't before.

If we need this behavioral change my idea is to introduce a new sub-option
or keep table comments excluded unless explicitly opted in. Because after
changing the current behavior there is no way to implement old behavior.

Regards.

Jim Jones <jim.jones@uni-muenster.de>, 22 Şub 2026 Paz, 13:34 tarihinde
şunu yazdı:

On 26/02/2026 08:46, Hüseyin Demir wrote:

Yes, because changing the behavior will lead to misinterpretations while
creating tables and tables derived from template ones will be presented
differently with respect to comments they have.

But isn't that the case to any feature that we add to CREATE TABLE LIKE?
For instance, if we add INCLUDING TRIGGERS, it will inevitably change
the behaviour of INCLUDING ALL.

Such changes can cause unexpected different objects inside a database.
For example, any existing script using INCLUDING COMMENTS or INCLUDING
ALL will now copy the table comment where it didn't before. 

That's true, the newly created table would then get a comment it didn't
have before. I just fail to see how this would create an unexpected
different object.

Of course, if this script relies on the table not having a comment to
work, it could case some problems.

If we need this behavioral change my idea is to introduce a new sub-
option or keep table comments excluded unless explicitly opted in.
Because after changing the current behavior there is no way to implement
old behavior. 

The user can always use EXCLUDING COMMENTS for that

CREATE TABLE t2 (
LIKE t1
INCLUDING ALL
EXCLUDING COMMENTS
);

Thanks, Hüseyin!

Best, Jim

On 13/02/2026 10:19, Jim Jones wrote:

...
Example:

CREATE TABLE t1 (a int);
COMMENT ON TABLE t1 IS 'comment from table 1';
CREATE TABLE t2 (b int);
COMMENT ON TABLE t2 IS 'comment from table 2';
CREATE TABLE t3 (c int);
COMMENT ON TABLE t3 IS 'comment from table 3';

CREATE TABLE tm (
LIKE t1 INCLUDING COMMENTS,
LIKE t3 INCLUDING COMMENTS,
LIKE t2 INCLUDING COMMENTS
);

SELECT obj_description('tm'::regclass, 'pg_class') AS table_comment;
table_comment
----------------------
comment from table 1+
comment from table 3+
comment from table 2
(1 row)

Any thoughts on that?

Rebase

Best, Jim