Re: COMMENTS are not being copied in CREATE TABLE LIKE

From: Hüseyin Demir <huseyin(dot)d3r(at)gmail(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
Subject: Re: COMMENTS are not being copied in CREATE TABLE LIKE
Date: 2026-02-22 08:05:19
Message-ID: 177174751973.626.7673368092428390674.pgcf@coridan.postgresql.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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"), unlike column or constraint comments which describe the schema structure. Copying them by default may be wrong more often than 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 pulls in. Silently copying a source table's comment (which might say something like "template — do not use directly") into every 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 behavior under INCLUDING COMMENTS.

Before reviewing the patch for code quality and repo standards, I think we need to decide whether this behavior change is the right approach at all. My preference would be to keep table comments managed separately, given the situations above.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mikael Kjellström 2026-02-22 08:31:17 Re: ecpg test thread/alloc hangs on sidewinder running NetBSD 9.3
Previous Message Michael Paquier 2026-02-22 06:19:29 Re: DOCS - Add an "Options" section for pg_controldata