>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) [email protected]
