Repository navigation
Add support for all binary and hexadecimal literal syntaxes - #245
Merged
Merged
Conversation
adamziel
reviewed
Sep 17, 2025
| // 0b... | ||
| $value = substr( $value, 2 ); | ||
| } else { | ||
| // b'...' or B'...' |
Collaborator
There was a problem hiding this comment.
Should we also account for X'01', x'01', _binary X'01', and _binary x'01'? Or are these fine because we can just preserve them as they are and we won't see them in this else?
Member
Author
There was a problem hiding this comment.
@adamziel X'01' and x'01' will be HEX literals and processed in the case below (HEX_NUMBER). So they should never appear under the WP_MySQL_Lexer::BIN_NUMBER token. These are valid in SQLite, so that case leaves them as is (only 0x... is translated).
For _binary x'01', I think the cast syntax will fail in SQLite at the moment, but behavior-wise, it should be fine, as both x'41' and _binary x'41' represent the same binary bytes — with SELECT, you get A as a result in both cases.
adamziel
approved these changes
Sep 17, 2025
This comment was marked as off-topic.
This comment was marked as off-topic.
JanJakes
added a commit
that referenced
this pull request
Oct 2, 2025
…tation (#255) This fixes the following error: ```bash SQLSTATE[HY000]: General error: 1 unrecognized token: "x'1'" ``` For queries like the following: ```sql SELECT 0b1; SELECT 0b01; SELECT 0b001; ... ``` SQLite doesn't have binary string literals, so [we need to convert them to HEX string literals](#245). However, HEX string literals in SQLite must be aligned to full bytes (their length needs to be even) — `x'01'` is valid, while `x'1'` is invalid. In MySQL, binary strings don't require such alignment, and `0b1` is valid (and `SELECT 0b1 = 0b01` returns `true`). Additionally, the `base_convert()` function used in the [original implementation](#245) doesn't preserve existing leading `0` padding. To solve both of these issues, this PR implements the following: 1. Count how many full bytes the original binary string requires. 2. Make sure the resulting HEX string has that number of bytes, using leading `0` padding. For HEX strings, this fix is not needed, as those require to be byte-aligned also in MySQL, so throwing an error for `x'1'` is actually correct.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add support for all binary and hexadecimal literal syntaxes. The differences are:
0x…is a binary literal, while in SQLite it’s a numeric one.0b...,b'...', andB'...'syntaxes can be used to represent binary literals. SQLite only supports HEX literals (x'...').This PR implements the following conversions:
0x...tox'...'.0b...,b'...', andB'...'tox'...'with binary to hexadecimal conversion.