Re: COMMENTS are not being copied in CREATE TABLE LIKE

On 20/07/2026 15:24, ZizhuanLiu X-MAN wrote:
> I’ve been thinking about the scenario where multiple source tables are used, and here are my concerns:
> 1. Even putting aside the problem of bloated combined text, we need to consider whether
> concatenating all source table comments delivers what developers, DBAs and business users
> actually expect. Can the merged description accurately reflect the intended purpose of the
> newly created table?
>
> 2. If we do implement comment concatenation, what merging rules should we adopt?
> Should we cap the number of source tables whose comments get merged, or impose
> a maximum character limit on the final combined text? Whichever restriction we pick
> will likely require truncating parts of the original comments. After truncation, can the
> resulting text still match what users intend to document?
>
> 3. In both cases outlined above, I believe the merged result will fail to satisfy users in
> most real-world scenarios. Even if we build this merging logic, users will still end up
> having to manually rewrite the table comment afterwards to fix it(Unless he does not
> care about it). Given that extra manual cleanup work would be unavoidable, it may
> be better to skip copying table-level comments entirely for multi-table cases.
>
> 4. It is indeed tricky to strike a balance between consistent feature behavior and intuitive,
> reasonable usability, which is exactly why we’re having this discussion. Our ultimate goal is
> to deliver a smooth experience for end users, so I think it makes sense to shape the design
> around the needs of the vast majority of users in their common use cases.

These are good points, but I'd argue that excluding multiple tables from
this feature would be hard to justify. Some of these points can be made
to column comments as well -- we cannot guarantee their semantics in the
new table, and yet we allow them to be copied.

postgres=# CREATE TABLE t1 (a int);
COMMENT ON COLUMN t1.a IS 'foo';
CREATE TABLE t2 (b int);
COMMENT ON COLUMN t2.b IS 'bar';

CREATE TABLE tm (
LIKE t1 INCLUDING COMMENTS,
LIKE t2 INCLUDING COMMENTS
);
CREATE TABLE
COMMENT
CREATE TABLE
COMMENT
CREATE TABLE
postgres=# SELECT
col_description('tm'::regclass::oid, 1),
col_description('tm'::regclass::oid, 2);
col_description | col_description
-----------------+-----------------
foo | bar
(1 row)

In this case is up to user to either make sure the column comments are
"transferable" or to correct them in the target table -- which is also
my case on including the table comments.

I'm not totally against dropping comments for multiple tables, but I
want to make sure our arguments against having them make sense. If we
conclude that it's impractical to concatenate table comments we should
also consider the option of withdrawing the patch -- it's not like I'm
terribly in love with it :)

Thanks for the input!

Best, Jim