Обсуждение: COMMENTS are not being copied in CREATE TABLE LIKE

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:


psql (19devel)
Type "help" for help.

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 | table comment | table comment
(1 row)



Thoughts?

Best, Jim

1 -
https://www.postgresql.org/message-id/flat/DG7Y34A6VBEG.76L7K1OML5DI%40gmail.com

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')
ASt2_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] 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

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

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?

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 -
https://www.postgresql.org/message-id/flat/20090907114058.C855.52131E4D%40oss.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"),
unlikecolumn or constraint comments which describe the schema structure. Copying them by default may be wrong more
oftenthan 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
pullsin. Silently copying a source table's comment (which might say something like "template — do not use directly")
intoevery 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
behaviorunder INCLUDING COMMENTS.
 

Before reviewing the patch for code quality and repo standards, I think we need to decide whether this behavior change
isthe 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"),
unlikecolumn or constraint comments which describe the schema structure. Copying them by default may be wrong more
oftenthan 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
pullsin. Silently copying a source table's comment (which might say something like "template — do not use directly")
intoevery 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
changeis the right approach at all. My preference would be to keep table comments managed separately, given the
situationsabove.
 


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/

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

Hi Carlos

On 24/03/2026 19:32, Carlos Alves wrote:
> Just one point I'd like to address is the documentation. Following the
> idea of the other "includings" options wouldn't it be interesting to
> present a more concise text? As a suggestion, it could be something like:
> 
> "Comments on columns, not null and check constraints, indexes, extended
> statistics and the table itself from a source table will be copied. If
> the command references multiple source tables with including clauses,
> any existing table-level comments will be merged into a single entry,
> separated by newlines in the order they were specified."

In the second paragraph of the INCLUDING COMMENTS docs I wrote:

<para>
  If multiple <literal>LIKE</literal> clauses specify
  <literal>INCLUDING COMMENTS</literal> and the source tables have
  table-level comments, these comments will be concatenated in the new
  table, separated by newlines, in the order that the
  <literal>LIKE</literal> clauses appear.
</para>

Which pretty much states the same? Please let me know if I am missing
your point here.


> I've attached some preliminary tests I performed.

Thanks for the thorough tests. Much appreciated!

Best, Jim

The following review has been posted through the commitfest application:
make installcheck-world:  tested, passed
Implements feature:       tested, passed
Spec compliant:           not tested
Documentation:            tested, passed

Hi Jim!

The tests performed were as follows:

1. Basic: creating a table from another table containing comments and without comments;

2. Multiple tables: containing comments, without comments, changing the order of the tables;

3. Overriding inclusion and exclusion directives;

4. Comments with line breaks and special characters;

5. Creation of a table involving hundreds of original tables (stress test);

6. Comments in other structures: fields, indexes, constraints;

7. Output generated by pg_dump;

8. Documentation

No errors or failures were detected during the tests.

The only suggestion is to keep the parameter description a single paragraph, following the same style as the
descriptionof the other inclusion parameters. But the current description is coherent and okay.
 

After the tests, the patch is working as expected:
- Table-level comments are copied when the `including comments` parameter is used.
- When there is more than one source table, comments, if any, are kept in the order in which they appear in the
command,separated by a new line.
 
- The performance of command execution was not affected.

I think only the code review is missing, but I don't have much experience to perform this step.

Best regards, 
Carlos

Hi Carlos

On 26/03/2026 18:59, Carlos Alves wrote:
> No errors or failures were detected during the tests.
> 
> The only suggestion is to keep the parameter description a single paragraph, following the same style as the
descriptionof the other inclusion parameters. But the current description is coherent and okay.
 
> 
> After the tests, the patch is working as expected:
> - Table-level comments are copied when the `including comments` parameter is used.
> - When there is more than one source table, comments, if any, are kept in the order in which they appear in the
command,separated by a new line.
 
> - The performance of command execution was not affected.
> 
> I think only the code review is missing, but I don't have much experience to perform this step.


Thanks for this thorough review. This helps a lot!
Let's see what the other reviewers have to say about the code and your
docs suggestion.

Best, Jim