MIME-Version: 1.0
References: <e08cb97f-0364-4002-9cda-3c16b42e4136@uni-muenster.de>
 <5888209c-44b5-438a-abd3-7d07990b3a4c@uni-muenster.de> <177174751973.626.7673368092428390674.pgcf@coridan.postgresql.org>
 <cc2e7c77-2ff6-4ab0-9bab-f9e6ba5cf6b4@uni-muenster.de>
In-Reply-To: <cc2e7c77-2ff6-4ab0-9bab-f9e6ba5cf6b4@uni-muenster.de>
From: =?UTF-8?Q?H=C3=BCseyin_Demir?= <huseyin.d3r@gmail.com>
Date: Thu, 26 Feb 2026 08:46:14 +0100
Message-ID: <CAB5wL7Yp3o4yYdxQ6mBVV6B-s80BmueizkKmZHEC632wYPp8Bw@mail.gmail.com>
Subject: Re: COMMENTS are not being copied in CREATE TABLE LIKE
To: Jim Jones <jim.jones@uni-muenster.de>
Cc: pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000004e9a18064bb55184"
Archived-At: <https://www.postgresql.org/message-id/CAB5wL7Yp3o4yYdxQ6mBVV6B-s80BmueizkKmZHEC632wYPp8Bw%40mail.gmail.com>
Precedence: bulk

--0000000000004e9a18064bb55184
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jim,

> Are you suggesting we should simply keep ignoring the table comments? Or
> should we manage them differently?

Yes, because changing the behavior will lead to misinterpretations while
creating tables and tables derived from template ones will be presented
differently with respect to comments they have.

Such changes can cause unexpected different objects inside a database.
For example, any existing script using INCLUDING COMMENTS or INCLUDING ALL
will now copy the table comment where it didn't before.

If we need this behavioral change my idea is to introduce a new sub-option
or keep table comments excluded unless explicitly opted in. Because after
changing the current behavior there is no way to implement old behavior.

Regards.


Jim Jones <jim.jones@uni-muenster.de>, 22 =C5=9Eub 2026 Paz, 13:34 tarihind=
e
=C5=9Funu yazd=C4=B1:

> Hi H=C3=BCseyin
>
> On 22/02/2026 09:05, H=C3=BCseyin Demir wrote:
> > 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.
>
> Good point. Comments may well lose their semantic value when placed in a
> different context, but I'm not sure how it differs from column comments.
> A column comment can also refer to a context (original table) that is no
> longer applicable after cloning, specially when the CREATE TABLE LIKE
> includes multiple tables.
>
>
> > 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 =E2=80=
=94 do not
> use directly") into every derived table could cause confusion in practice=
.
>
>
> It's also a valid concern - although I see it slightly differently. I we
> take this line of reasoning too seriously, we might never be able to
> expand CREATE TABLE LIKE, since the ALL keyword would be directly
> affected (expanded) in the process. There are also other patches that
> aim to expand CREATE TABLE LIKE, e.g. INCLUDING TRIGGERS[1]
>
>
> > 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.
>
>
> Are you suggesting we should simply keep ignoring the table comments? Or
> should we manage them differently?
>
> Thanks for the comments. Much appreciated!
>
> Best, Jim
>
> 1 - https://commitfest.postgresql.org/patch/6087/
>

--0000000000004e9a18064bb55184
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Jim,=C2=A0<div><br></div><div>&gt; Are you suggesting w=
e should simply keep ignoring the table comments? Or</div>&gt; should we ma=
nage them differently?<div><br></div><div>Yes, because changing the behavio=
r will lead to misinterpretations while creating tables and tables derived =
from template ones will be presented differently with respect to comments t=
hey have.</div><div><br></div><div>Such changes can cause unexpected differ=
ent objects inside a database. For=C2=A0example, any existing script using =
INCLUDING COMMENTS or INCLUDING ALL will now copy the table comment where i=
t didn&#39;t before.=C2=A0</div><div><br></div><div>If we need this behavio=
ral change my idea is to introduce a new sub-option or keep table comments =
excluded unless explicitly opted in. Because=C2=A0after changing the curren=
t behavior there is no way to implement old behavior.=C2=A0</div><div><br><=
/div><div>Regards.</div><div><br></div></div><br><div class=3D"gmail_quote =
gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">Jim Jones &lt;=
<a href=3D"mailto:jim.jones@uni-muenster.de">jim.jones@uni-muenster.de</a>&=
gt;, 22 =C5=9Eub 2026 Paz, 13:34 tarihinde =C5=9Funu yazd=C4=B1:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">Hi H=C3=BCseyin<br>
<br>
On 22/02/2026 09:05, H=C3=BCseyin Demir wrote:<br>
&gt; 1. Table comments tend to describe the purpose or context of a specifi=
c table (e.g. &quot;staging table for pipeline X&quot;), unlike column or c=
onstraint comments which describe the schema structure. Copying them by def=
ault may be wrong more often than it&#39;s right, since the new table almos=
t certainly serves a different purpose than the source.<br>
<br>
Good point. Comments may well lose their semantic value when placed in a<br=
>
different context, but I&#39;m not sure how it differs from column comments=
.<br>
A column comment can also refer to a context (original table) that is no<br=
>
longer applicable after cloning, specially when the CREATE TABLE LIKE<br>
includes multiple tables.<br>
<br>
<br>
&gt; 2. This changes the behavior of INCLUDING ALL, which many users rely o=
n without thinking too carefully about what it pulls in. Silently copying a=
 source table&#39;s comment (which might say something like &quot;template =
=E2=80=94 do not use directly&quot;) into every derived table could cause c=
onfusion in practice.<br>
<br>
<br>
It&#39;s also a valid concern - although I see it slightly differently. I w=
e<br>
take this line of reasoning too seriously, we might never be able to<br>
expand CREATE TABLE LIKE, since the ALL keyword would be directly<br>
affected (expanded) in the process. There are also other patches that<br>
aim to expand CREATE TABLE LIKE, e.g. INCLUDING TRIGGERS[1]<br>
<br>
<br>
&gt; Before reviewing the patch for code quality and repo standards, I thin=
k we need to decide whether this behavior change is the right approach at a=
ll. My preference would be to keep table comments managed separately, given=
 the situations above.<br>
<br>
<br>
Are you suggesting we should simply keep ignoring the table comments? Or<br=
>
should we manage them differently?<br>
<br>
Thanks for the comments. Much appreciated!<br>
<br>
Best, Jim<br>
<br>
1 - <a href=3D"https://commitfest.postgresql.org/patch/6087/" rel=3D"norefe=
rrer" target=3D"_blank">https://commitfest.postgresql.org/patch/6087/</a><b=
r>
</blockquote></div>

--0000000000004e9a18064bb55184--