Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.700.51.1.1\))
Subject: Re: COMMENTS are not being copied in CREATE TABLE LIKE
From: Alex Liapychev <coder.sam@gmail.com>
In-Reply-To: <c8525e6e-5789-464e-a70d-b3916e4168eb@uni-muenster.de>
Date: Sun, 27 Sep 2026 02:23:25 +0200
Cc: matheusssilv97 <matheusssilv97@gmail.com>,
 Chao Li <li.evan.chao@gmail.com>,
 "masao.fujii" <masao.fujii@gmail.com>,
 "david.g.johnston" <david.g.johnston@gmail.com>,
 tgl <tgl@sss.pgh.pa.us>,
 "huseyin.d3r" <huseyin.d3r@gmail.com>,
 pgsql-hackers <pgsql-hackers@lists.postgresql.org>,
 chochoforwork@gmail.com,
 44973863@qq.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <CAD4C109-0CAB-4D25-9C3B-FDC8CE375E4D@gmail.com>
References: <e08cb97f-0364-4002-9cda-3c16b42e4136@uni-muenster.de>
 <tencent_D0A4135EDF6E96A0D4478DABF0656D6DB408@qq.com>
 <2d41978b-3bca-4756-b0a0-b6e707ad7793@uni-muenster.de>
 <tencent_FF05EDF384FEB7852516F57BE32C7C61DB06@qq.com>
 <88b16128-d6f4-4a7b-a29a-fa0cd1c2084f@uni-muenster.de>
 <tencent_28945AA8110B3EA5AD8A366542E61BCA5205@qq.com>
 <65963A8C-C1EE-431E-9513-C4AD16AEE789@gmail.com>
 <223a6be3-3917-47a4-9b5d-51720c60ad58@vondra.me>
 <c8525e6e-5789-464e-a70d-b3916e4168eb@uni-muenster.de>
To: Jim Jones <jim.jones@uni-muenster.de>,
 tomas@vondra.me
Archived-At: 
 <https://www.postgresql.org/message-id/CAD4C109-0CAB-4D25-9C3B-FDC8CE375E4D%40gmail.com>
Precedence: bulk

Hi Jim and Tomas, everyone,

Thank you Tomas for stepping in and putting things into perspective.=20
Thank you Jim for making the changes so quickly.

We did a recheck of the new version v4 of the patch on September 26, =
2026.
Branch cf/6482 (commit: 47ed4119) rebased over master (commit: =
f25c50fd).
Tests on both master alone and with cf/6482 on top completed =
successfully.

V4 is a complete rewrite.

Author fixed all issues pointed by Tomas and by us (see 3 previous =
messages).

I will list notable changes briefly:
1. Docs: create_table.sgml:695 - replaced =E2=80=9Ctable=E2=80=9D for =
=E2=80=9Csource relation=E2=80=9D, because it could be other types of =
relations.
2. Tests: added INCLUDING ALL test case; test cases for concatenation =
corner cases; foreign and temporary table as copy target cases; type as =
a source case.

3. Code review of a file parse_utilcmd.c:
3.1. Includes are now sorted in alphabetical order.
3.2. Case when concatenated comment exceeds MaxAllocSize:
>>> 1. Corner case: concatenation of big comments, whose total size =
exceeds MaxAllocSize, fails with an error.

>> I'd just reject such cases, with an ERROR that says the comment would =
be
>> too long. It's cleaner than just silently start discarding user
>> information. The number of people hitting this is about 0 anyway. Who
>> would even have comments of this size?

Implemented on L:1369-1374, error ERRCODE_PROGRAM_LIMIT_EXCEEDED is =
returned with clear message.

3.3. Memory allocation and freeing:
>> FWIW if we really are worried about very long comments, then maybe
>> expandTableLikeClause should be more careful about freeing comments
>> during the concatenation? Right now it keeps all the comments and =
then
>> also the intermediate strings during concatenation. (I think.)

I tried to trace memory allocations, there are 2 scopes where =
allocations happen:

3.3.a. The local scope, where comment of each LIKE relation is read:
- allocated: in GetComment (L:1348 or 1352);
- freed: pfree(tblcomment) at L:1379;
Seems good.

3.3.b. Scope of transformCreateStmt function:

- defined: Variable cxt (CreateStmtContext) is created on stack (at =
L:176), inside is new field tablecomment (StringInfo).=20
- - It is NULLed before first use at L:257.

- allocated: Field cxt->tablecomment is initialised at L:1361 via =
makeStringInfo(), which does 2 palloc=E2=80=99s internally.
- read: cxt.tablecomment->data is stored into cstmt->comment at L:321.
- freed: NEVER.=20

destroyStringInfo is not called from parse_utilcmd.c.=20
Which seems correct, because we pass data to outside of a function.
But probably we should call pfree for cxt.tablecomment (StringInfo =
struct itself) to balance 1st palloc from makeStringInfo.

3.3.c. (bonus) Scope where de-allocation also might happen:

Comment produced in transformCreateStmt function then reaches code from =
file comment.c, where it is stored to target relation.

I could not find any pfree for stmt->comment inside the file comment.c, =
where it is consumed.
Which should exist to balance 2nd palloc from makeStringInfo.

I don=E2=80=99t know if this palloc'd memory is freed somehow =
automagically at some later point.
But to my understanding it may be a memory leak, which spans past this =
specific patch scope.


4. The question if we should concat comments at all:
>> That being said, I'm not convinced we actually want to concatenate
>> comments like this. It feels a bit weird, and it can probably lead to
>> weird stuff like "duplicate" comments, etc. Do we have any precedent =
for
>> this behavior? Are we concatenating comments (or other stuff) =
anywhere?
>> I couldn't find such place, but maybe I missed something.
>=20
> Neither am I. I'm just not sure that ignoring the comments when using
> multiple tables is a better alternative. I can live with it, but so =
far
> I didn't find enough arguments to remove it. The alternatives I see =
are:
>=20
> 1) concatenate with a (\n) separator (current behaviour)
> 2) concatenate without a separator
> 3) first one wins
> 4) last one wins
> 5) ignore it altogether when multiple comments are detected (my least
> favourite)
> 6) your idea? :)
>=20
> WDYT?

I think from perspective of semantics of INCLUDING COMMENTS/ALL it seems =
right to copy comments of a table.
But for such complicated scenario, where there are few source relations =
- not sure.

Maybe "last one wins" would be the easiest to implement and least =
counter-intuitive for users?

This concatenation code works, but what consequences it may have to =
support it over years?

Kind regards,
Alex Liapychev