Description:
On MySQL 26.7.0, converting a VECTOR value to a string with VECTOR_TO_STRING() and parsing it again with STRING_TO_VECTOR() changes the binary vector value.
The MySQL 26.7 Reference Manual describes VECTOR_TO_STRING() as the inverse of STRING_TO_VECTOR(). Since VECTOR elements are 4-byte single-precision floating-point values, I expected this conversion round-trip to preserve the original vector value.
For the input [1.234567], the original vector is 4B069E3F, but the round-tripped vector is 64069E3F. The equality check returns 0. This indicates that the string representation does not retain enough precision to reconstruct the original value.
How to repeat:
Run this statement on MySQL 26.7.0:
SELECT VERSION() AS server_version,
HEX(STRING_TO_VECTOR('[1.234567]')) AS original_hex,
VECTOR_TO_STRING(STRING_TO_VECTOR('[1.234567]')) AS rendered,
HEX(STRING_TO_VECTOR(VECTOR_TO_STRING(STRING_TO_VECTOR('[1.234567]')))) AS roundtrip_hex,
(STRING_TO_VECTOR('[1.234567]') =
STRING_TO_VECTOR(VECTOR_TO_STRING(STRING_TO_VECTOR('[1.234567]')))) AS exact_roundtrip;
Observed output:
server_version: 26.7.0
original_hex: 4B069E3F
rendered: [1.23457e+00]
roundtrip_hex: 64069E3F
exact_roundtrip: 0
Suggested fix:
Format VECTOR elements with enough significant decimal digits to allow STRING_TO_VECTOR() to reconstruct the original single-precision value (for example, using a round-trip-safe precision). If this conversion is intentionally lossy, please clarify that limitation in the documentation.
Description: On MySQL 26.7.0, converting a VECTOR value to a string with VECTOR_TO_STRING() and parsing it again with STRING_TO_VECTOR() changes the binary vector value. The MySQL 26.7 Reference Manual describes VECTOR_TO_STRING() as the inverse of STRING_TO_VECTOR(). Since VECTOR elements are 4-byte single-precision floating-point values, I expected this conversion round-trip to preserve the original vector value. For the input [1.234567], the original vector is 4B069E3F, but the round-tripped vector is 64069E3F. The equality check returns 0. This indicates that the string representation does not retain enough precision to reconstruct the original value. How to repeat: Run this statement on MySQL 26.7.0: SELECT VERSION() AS server_version, HEX(STRING_TO_VECTOR('[1.234567]')) AS original_hex, VECTOR_TO_STRING(STRING_TO_VECTOR('[1.234567]')) AS rendered, HEX(STRING_TO_VECTOR(VECTOR_TO_STRING(STRING_TO_VECTOR('[1.234567]')))) AS roundtrip_hex, (STRING_TO_VECTOR('[1.234567]') = STRING_TO_VECTOR(VECTOR_TO_STRING(STRING_TO_VECTOR('[1.234567]')))) AS exact_roundtrip; Observed output: server_version: 26.7.0 original_hex: 4B069E3F rendered: [1.23457e+00] roundtrip_hex: 64069E3F exact_roundtrip: 0 Suggested fix: Format VECTOR elements with enough significant decimal digits to allow STRING_TO_VECTOR() to reconstruct the original single-precision value (for example, using a round-trip-safe precision). If this conversion is intentionally lossy, please clarify that limitation in the documentation.