Bug #113414 reopen, query result is inconsistence when operands of differing types

• Submitted: 14 Dec 2023 6:23
• Modified: 14 Dec 2023 11:41
• Reporter: Shawn Yan (OCA)
• Status: Duplicate
• Category: MySQL Server: Data Types
• Severity: S3 (Non-critical)
• Version: 8.0
• OS: Any
• CPU Architecture: Any

[14 Dec 2023 6:23] Shawn Yan

Description:
could you reply this, and better not close the ticket directly? gentleman.

How to repeat:
https://bugs.mysql.com/bug.php?id=113403

[13 Dec 9:50] Shawn Yan

@Roy Lyseng

thank you for your quick reply,

> In that process, some lack of precision is expected, and thus results may be imprecise compared to expected behavior.

we don't think thus results are expected behavior. A lossless comparison is easier to accept.
if mysql is one of the best rdbms, should be able to do lossless imprecise conversion, not let end user to cover it.

meanwhile, we run this test case in other DB (like MariaDB, Oracle), and get expected results (3 rows in set).

more evidence, in Oracle doc, https://docs.oracle.com/cd/E73729_01/DR/Implicit_Conversion.html
INTEGER will convert to STRING

[14 Dec 2023 11:34] MySQL Verification Team

Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments to the original bug instead.

Your original bug is:

https://bugs.mysql.com/bug.php?id=113403

Please, post your comments in that bug report and you will get the answer.

Also, please do not refer to any other product, nor to the documentation that is not MySQL related, because this forum is for MySQL bugs, not the behaviour of other products.

Thank you for your interest in MySQL.

[14 Dec 2023 11:41] Shawn Yan

thank you for your reply,

then, please let developer team reply my question, I will wait.

https://bugs.mysql.com/bug.php?id=113403
we don't think thus results are expected behavior. A lossless comparison is easier to accept.
if mysql is one of the best rdbms, should be able to do lossless imprecise conversion, not let end user to cover it.