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

I ran some tests after applying your patch and initially didn't find any problems. I tried to cover the main scenarios in a focused way, observing the generated results.

Regarding the possibility of including comments in the table itself using the LIKE clause, it seems sensible since other elements like columns, indexes, and constraints have copied comments, as already discussed in the thread.

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

I've attached some preliminary tests I performed.

Thank you in advance for your attention.