Re: COMMENTS are not being copied in CREATE TABLE LIKE

Hello Jim,
Hello everyone,

Thank you Jim and all the reviewers for working on this patch.

We reviewed the patch version v3 on September 20, 2026.

The patch aims to fill the gap in CREATE TABLE LIKE functionality, where INCLUDING COMMENTS or INCLUDING ALL does not copy a comment of a Table itself.
While there is still a discussion going on, if the table's own comment is worth copying at all, we concentrated on reviewing implementation itself.

Patch set structure is good: description of what was done and why, documentation and tests included.
We compiled the patch from branch cf/6482 (commit: 451748bf) against master (commit: 9e17d25e79d) on MacOS (version 26.6.2) on Intel hardware.
Run standard tests(meson tests) and executed manual tests in psql. Tests in both master and cf/6482 completed successfully.

Below are our findings:

1. Corner case: concatenation of big comments, whose total size exceeds MaxAllocSize, fails with an error.
Here is the test case to prove that:
```
CREATE TABLE comment_1gb_test (id BIGINT);
-- set comment 1 GiB in size
UPDATE pg_catalog.pg_description
SET description = pg_catalog.repeat('x', 1000000000)
WHERE classoid = 'pg_catalog.pg_class'::regclass
AND objoid = 'public.comment_1gb_test'::regclass
AND objsubid = 0;
SELECT octet_length(description) as comment_size_bytes FROM pg_catalog.pg_description WHERE classoid = 'pg_catalog.pg_class'::regclass AND objoid = 'public.comment_1gb_test'::regclass AND objsubid = 0;
comment_size_bytes
--------------------
1000000000
(1 row)
CREATE TABLE xxl1 (LIKE comment_1gb_test INCLUDING ALL);
CREATE TABLE xxl2 (LIKE comment_1gb_test INCLUDING ALL);
ALTER TABLE xxl2 RENAME COLUMN id TO id2;

CREATE TABLE merge_xxl (LIKE xxl1 INCLUDING ALL, LIKE xxl2 INCLUDING ALL);
ERROR: string buffer exceeds maximum allowed length (1073741823 bytes)
DETAIL: Cannot enlarge string buffer containing 1000000001 bytes by 1000000000 more bytes.
```
Some form of truncation should be applied, cap the total size is easiest: first table's comment takes an advantage, others - as fit.

2. Code review notes:
2.1. nitpick: parse_utilcmd.c:46: order of includes would be better if added include ("lib/stringinfo.h") was placed either before "miscadmin.h" (alphabetical order) or before "utils/..." (functional order).
2.2. nitpick: parse_utilcmd.c:1652: it would match style of surrounding code better if local variable `CommentStmt *stmt` would be named `comment_stmt`; see code above in the same function: `stats_stmt` (line 1618), `index_stmt` (line 1577), etc.
2.3. nitpick: create_table_like.out:486 & create_table_like.sql:198: Since behaviour of INCLUDING ALL has also been changed by this patch. It would be better to update the tests to cover it.

Thank you very much for your attention.
Kind regards,
Eddie Cho and Alex Liapychev

P.S.
This is our first review, it was done together within a Postgres Patch Review Workshop: Sept 2026.
Thank you, Paul A. Jungwirth, for your efforts to welcome newcomers and involve them in meaningful work on PostgreSQL.