Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xC3Vd-00000003Wzj-1z5S for pgsql-hackers@arkaria.postgresql.org; Wed, 30 Sep 2026 23:14:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xC3VR-00000004KTe-17iZ for pgsql-hackers@arkaria.postgresql.org; Wed, 30 Sep 2026 23:14:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xC3VQ-00000004KTU-2hyw for pgsql-hackers@lists.postgresql.org; Wed, 30 Sep 2026 23:14:32 +0000 Received: from mail-ed2-x0c.google.com ([2a00:1450:4864:33::c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1xC3VN-000000026lv-4Aif for pgsql-hackers@lists.postgresql.org; Wed, 30 Sep 2026 23:14:31 +0000 Received: by mail-ed2-x0c.google.com with SMTP id 4fb4d7f45d1cf-6aeeccb7d59so129516a12.2 for ; Wed, 30 Sep 2026 16:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790810068; x=1791414868; darn=lists.postgresql.org; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type :message-id:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=hBtbL03DFGF5znluDylpggS+i6yktSbMJi3VHJei7JI=; b=IyZmBZOpmyW4YEcEND6Ye8UIgz2QLkvMW/Aee10ZCTQ83HYkAPulgJtJesa/NGHkL1 bw3fysNcLfRPR7Q/7+gdsZt+0n6x1u2JuKbU1YGfEP8FnisoH5soL2mkYwrRrzGrMNrC 2UrDtSGjHzDGnzPbMvx6J9b/4dakv7x++XI3F6D7yRJ4UiaLsu8W5oXJPDSsQYdqmac6 GcnRLHsMOPKUBSEQ48hSO4rxp7oYhNgsZxJw6BbXrjlsRQ22QZLMMJMyUl4Q7aM455Dd i+JKyUoAtTrICH5xjFnmcMZ/TUU2sgLtBpWYEVWgduJqc/Dg3rO9/srBTQUNmQLMmNF6 21Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790810068; x=1791414868; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type :message-id:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=hBtbL03DFGF5znluDylpggS+i6yktSbMJi3VHJei7JI=; b=kUJ9KHXtMdodokh0wgoHvs1Gor1P9D8thR/PYsbX73gwMJfnngBxHDEhzNqYOFOWPe oGCyGY3KtQcoEfNvQkENCMvsgZhd5+rgSNCG/BFoUJR8wgc58bJuYxvjBB2kHuiNbJBM 0TDuq8iNVs3ek1Zy9Y868u5TgUIyIfmi/8tieIzcKOl88NGdR6Ywdmnbl9R7yIwgn4ER 3B/TuRQT76kCyGiUYpFlSTbVc/nSAUoEItTM8hztEeTNuSFAMO90GxlQgeO+ofR2lll4 6uan81tJo//jyPTF5e3ZWzE9EIaK5hP3A5jQ5ZZjJX3VgRVgLT1IzrbikjOR2yF/Cj+J zvNw== X-Forwarded-Encrypted: i=1; AKwUvBxe+EsesJW3vNnVKgjJRTiD8KbkD3PzqfD06fyVqU+J1/emi+mOGzYqGLaSkVQom6Sd4swTiJY30YRKD1i4@lists.postgresql.org X-Gm-Message-State: AFq9FYI/qkw2CqW1gU2W1j8UjFozyr/ArHRmeE3Uu7jliXhF4DbuMuPh SbpBZHrH3jJl4c/MftTbg0HnZj4S3UBaTogXryTjwEgHnnHdM2bMwwGh X-Gm-Gg: AYBFou0xydUFyaV6edfLCgoHDtz0z8IRaYEAvSsfuteJgeSOJyX3WUQALmqm4e+LTNU AZo8qZmP+lxn6nbJE+1VgG54Jc/dMcDRT7yv7EBXonEYcFbmgEUAApALUsMrCW4/HkHZISrWku3 DX0nf++dmCEXSCBA7c7D1lKdzbjLYuDf9o3SHFzEShvtHwN5FWol9x48aGTjr4eJz3KxmxcL9TM ZUWNcb6404yD+sUMIfLWqOl3vNoPIsBeoHS8YEH7/sOIDoYhwGE+zwe28PlprBDuZVFDtZCG920 w3zEgvByDu3A2NegALM6ONB2IcFBK5C68a7wLX0cZklIlusCHlaPfoJaItBYUp0oGYZj56Uf3sk rUt5C8hm/P45C+r4ZtuoNKYf9vrwfOfnp0FBACCVIyZ5De9V9kbzzkZUU0tYmXJFQ3pk+Vl+acY TJuWNIeS18z2+pmRIYhnnW4GCMa3t8dUj9dswaS6i7WrEkytP4JZvzGUbsU5B0SkAROMEj6vpW+ EK9CLyUrDEINt2AOyw= X-Received: by 2002:a05:6402:304b:b0:6ac:73f8:2e40 with SMTP id 4fb4d7f45d1cf-6ae1992a142mr1616070a12.27.1790810068307; Wed, 30 Sep 2026 16:14:28 -0700 (PDT) Received: from smtpclient.apple ([109.36.231.157]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6ae5ca44e64sm214428a12.8.2026.09.30.16.14.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Sep 2026 16:14:27 -0700 (PDT) From: Alex Liapychev Message-Id: <36F56BBE-1499-4F82-AC03-05AAAE65D657@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B9F72CC9-7CE8-4FF0-AD35-DB0C779A9D22" 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 Date: Thu, 1 Oct 2026 01:14:14 +0200 In-Reply-To: Cc: matheusssilv97 , Chao Li , "masao.fujii" , "david.g.johnston" , tgl , "huseyin.d3r" , pgsql-hackers , chochoforwork@gmail.com, 44973863@qq.com To: Jim Jones , tomas@vondra.me References: <2d41978b-3bca-4756-b0a0-b6e707ad7793@uni-muenster.de> <88b16128-d6f4-4a7b-a29a-fa0cd1c2084f@uni-muenster.de> <65963A8C-C1EE-431E-9513-C4AD16AEE789@gmail.com> <223a6be3-3917-47a4-9b5d-51720c60ad58@vondra.me> X-Mailer: Apple Mail (2.3864.700.51.1.1) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --Apple-Mail=_B9F72CC9-7CE8-4FF0-AD35-DB0C779A9D22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jim and Tomas, everyone, I dig the mailing list to find if there was anything related to copying = the table comments in the past. I have found thread starting on 2009-09-07, where =E2=80=9CCOMMENTS=E2=80=9D= was added to =E2=80=9CINCLUDING =E2=80=A6=E2=80=9D clause for the first = time: = https://www.postgresql.org/message-id/flat/20090907114058.C855.52131E4D%40= oss.ntt.co.jp Part of the discussion in this thread regarding COMMENTS goes around = columns, indexes and constraints. I could not find any mention of table=E2=80=99s own comment. My personal view is that adding this functionality carries more risks = than leaving it out. Although the code is relatively small and appears = to work correctly, I would not merge it into the codebase. An example of how this functionality could be used maliciously: A workflow creates a new table from several template tables in response = to an event. An adversarial user with sufficient database access adds one comment to = each of two template tables. The combined size of these comments exceeds = MaxAllocSize, causing the automation to fail unexpectedly. Kind regards, Alex Liapychev > On 27 Sep 2026, at 02:23, Alex Liapychev wrote: >=20 > Hi Jim and Tomas, everyone, >=20 > Thank you Tomas for stepping in and putting things into perspective.=20= > Thank you Jim for making the changes so quickly. >=20 > 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. >=20 > V4 is a complete rewrite. >=20 > Author fixed all issues pointed by Tomas and by us (see 3 previous = messages). >=20 > 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. >=20 > 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. >=20 >>> 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? >=20 > Implemented on L:1369-1374, error ERRCODE_PROGRAM_LIMIT_EXCEEDED is = returned with clear message. >=20 > 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.) >=20 > I tried to trace memory allocations, there are 2 scopes where = allocations happen: >=20 > 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. >=20 > 3.3.b. Scope of transformCreateStmt function: >=20 > - 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. >=20 > - 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 >=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. >=20 > 3.3.c. (bonus) Scope where de-allocation also might happen: >=20 > Comment produced in transformCreateStmt function then reaches code = from file comment.c, where it is stored to target relation. >=20 > 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. >=20 > 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. >=20 >=20 > 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? >=20 > 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. >=20 > Maybe "last one wins" would be the easiest to implement and least = counter-intuitive for users? >=20 > This concatenation code works, but what consequences it may have to = support it over years? >=20 > Kind regards, > Alex Liapychev >=20 >=20 --Apple-Mail=_B9F72CC9-7CE8-4FF0-AD35-DB0C779A9D22 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Jim and Tomas, = everyone,

I dig the mailing list to find if = there was anything related to copying the table comments in the = past.
I have found thread starting on 2009-09-07, where = =E2=80=9CCOMMENTS=E2=80=9D was added to =E2=80=9CINCLUDING =E2=80=A6=E2=80= =9D clause for the first time:

Part = of the discussion in this thread regarding COMMENTS goes around columns, = indexes and constraints.
I could not find any mention of = table=E2=80=99s own comment.

My personal view = is that adding this functionality carries more risks than leaving it = out. Although the code is relatively small and appears to work = correctly, I would not merge it into the codebase.

An = example of how this functionality could be used = maliciously:

  • A workflow creates a new table from several = template tables in response to an event.
  • An adversarial user = with sufficient database access adds one comment to each of two template = tables. The combined size of these comments exceeds MaxAllocSize, causing the automation to fail = unexpectedly.

Kind = regards,
Alex = Liapychev


On = 27 Sep 2026, at 02:23, Alex Liapychev <coder.sam@gmail.com> = wrote:

Hi Jim and = Tomas, everyone,

Thank you Tomas for stepping in and putting = things into perspective.
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).
- - 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.

destroyStringInfo = is not called from parse_utilcmd.c.
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.

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:

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? = :)

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



= --Apple-Mail=_B9F72CC9-7CE8-4FF0-AD35-DB0C779A9D22--