)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":31737,"name":"Hirotaka Wakabayashi","email":"hiwkby@yahoo.com","username":"hiwkby"},"change_message_id":"f03f6fc978505e017b6cc30b90ec5a36037a89c1","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"881708f7_a3d73454","updated":"2026-03-16 16:59:11.000000000","message":"Hi Eric, I appreciate the thorough investigation into MySQL identifier constraints.\n\nI agree that, in principle, we should support backslashes. However, given that backslashes are special characters (e.g., \\t), simply relaxing the validation isn\u0027t enough; we need to ensure proper escaping is handled consistently. This shifts the scope from a validation fix to an architectural discussion that requires a comprehensive impact analysis.\n\nSince Trove\u0027s current logic assumes \"clean\" database names without backslashes, allowing them would necessitate adding escaping logic across multiple components. Because of these broader implications, it\u0027s hard to justify merging this patch without seeing how it fits into a larger fix for the entire pipeline. What do you think?\n\nThanks,","commit_id":"870007d0c89d47a10e803c3c31dddb18dbe5108e"},{"author":{"_account_id":36080,"name":"Erkin Mussurmankulov","display_name":"Eric","email":"mangust404@gmail.com","username":"mongoose404","status":"PS Cloud services employee"},"change_message_id":"3f3f039919d7bebcdde27ab2eb2ef2a1680ec1a2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"1b83f8f3_f09543fb","in_reply_to":"881708f7_a3d73454","updated":"2026-03-17 13:34:44.000000000","message":"Yes, you\u0027re right. I will add unit tests to ensure that everything works fine without strict naming constraints and corresponding changes in tempest scenarios.","commit_id":"870007d0c89d47a10e803c3c31dddb18dbe5108e"}]}