Re: COMMENTS are not being copied in CREATE TABLE LIKE

>Hi ZizhuanLiu
>
>Thanks for the detailed review!
>
>On 18.07.26 16:03, ZizhuanLiu X-MAN wrote:
>> 3. In cases where multiple source tables are referenced in one `LIKE` clause, I suggest skipping table
>> comment copying entirely. Concatenating multiple disparate table comments would result in bloated
>> and confusing text that fails to accurately describe the intended purpose of the combined new table.
>
>I slightly disagree. I don't have a strong opinion about it, but I find
>this a rather unnecessary limitation. I do understand the concern of a
>bloated comment, but doing so we sort of imply that *all* table comments
>are not fit for this feature, which is arguably not accurate. IMHO, if
>the user explicitly wants the comments to be copied, we should not judge
>if the they make sense or not -- of course, given that the documentation
>describes the concatenation.
>
>What do you think?
>
>Thanks for the comments. Much appreciated!
>
>Best, Jim

Hi Jim,everyone

Thanks a lot for your feedback.

I’ve been thinking about the scenario where multiple source tables are used, and here are my concerns:
1. Even putting aside the problem of bloated combined text, we need to consider whether
concatenating all source table comments delivers what developers, DBAs and business users
actually expect. Can the merged description accurately reflect the intended purpose of the
newly created table?

2. If we do implement comment concatenation, what merging rules should we adopt?
Should we cap the number of source tables whose comments get merged, or impose
a maximum character limit on the final combined text? Whichever restriction we pick
will likely require truncating parts of the original comments. After truncation, can the
resulting text still match what users intend to document?

3. In both cases outlined above, I believe the merged result will fail to satisfy users in
most real-world scenarios. Even if we build this merging logic, users will still end up
having to manually rewrite the table comment afterwards to fix it(Unless he does not
care about it). Given that extra manual cleanup work would be unavoidable, it may
be better to skip copying table-level comments entirely for multi-table cases.

4. It is indeed tricky to strike a balance between consistent feature behavior and intuitive,
reasonable usability, which is exactly why we’re having this discussion. Our ultimate goal is
to deliver a smooth experience for end users, so I think it makes sense to shape the design
around the needs of the vast majority of users in their common use cases.

Looking forward to hearing more thoughts from everyone.

regards,
--
ZizhuanLiu (X-MAN) 
44973863(at)qq(dot)com