Re: COMMENTS are not being copied in CREATE TABLE LIKE

Hi Jim,
Hi Tomas and Tom,

First, let me address the specific questions.
> On 1 Oct 2026, at 18:49, Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> wrote:
>
> On 01/10/2026 01:14, Alex Liapychev wrote:
>>
>> 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.
>
> You mean the multiple tables scenario or the whole patch?

Yes, I meant the scenario involving multiple tables - specifically, the concatenation of their comments.
Sorry I wasn’t clear about that here.

>> 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.
>
> Can you elaborate more on this scenario? I'm afraid I didn't get your
> point here. Thanks!
>

I meant that CREATE TABLE is executed within some automatic flow, without direct human supervision.
For example, by a cron job or application’s code that executes CREATE TABLE in response to some 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.
>
> An "adversarial" user with enough privileges can do many things break
> it, like renaming a column causing a conflict. I see this large comment
> scenario as purely theoretical -- at least I fail to see any practical
> use case ever exhausting this limit.

Yes, this is a narrow and theoretical scenario. But introducing a way to break the application still creates a real vulnerability, even if it requires very specific conditions. The delay between the adversary’s action (adding long comments) and the resulting failure (when CREATE TABLE actually runs) makes the cause harder to identify and can help the adversary remain undetected longer.

Second, let me explain my overall assessment.

First of all, the code itself in v4 looks good. (The question of freeing memory that I had, is answered by the Memory Contexts.)

My concern is less about the implementation itself than about whether the benefit justifies the long-term maintenance burden and the potential security risk, however theoretical.

As Tomas and Tom’s comments have highlighted, the underlying issue is the lack of a clear use case.
A concrete, practical use case would help establish whether those costs and risks are justified at all, and which alternative to concatenation to pick.

That said, this is just my assessment as a reviewer.

Thank you for your work on this patch and for taking the time to discuss these concerns.

Kind regards,
Alex Liapychev