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.
