Jackie-Jiang commented on issue #12457:
URL: https://github.com/apache/pinot/issues/12457#issuecomment-1957637578
Thanks for the comprehensive explanation of the problem!
- V1 is not strong typed, and for historic reason Pinot used to only take
string as literal. That is the reason why we use hex encoded string to
represent binary, and does implicit cast with hex encoding.
- On the contrast, V2 is strong typed, so in order to compare with a BYTES
column, literal needs to be binary type. The most straight forward way is to
directly declare the literal as binary (e.g.
`X'80c062bc98021f94f1404e9bda0f6b0202 '`). When
`'80c062bc98021f94f1404e9bda0f6b0202'` is used, it is initially parsed as
unknown type, thus Calcite will try to `CAST` it to binary to match the LHS. If
RHS is explicit string type (e.g. `CAST('80c062bc98021f94f1404e9bda0f6b0202' AS
varchar)`), it should fail because binary and varchar are not compatible.
- To reduce the confusion, I'm suggesting doing the following:
- Keep the V1 implicit hex encoding as is, but make it accept explicit
binary (e.g. `X'80c062bc98021f94f1404e9bda0f6b0202 '`)
- Throw exception in V2 when encountering implicit string to binary
conversion with proper error message to guide the user to use explicit binary
For the non-literal comparison, it is actually a different issue. In V1,
`colA = colB` is rewritten to `colA - colB = 0`, where the `minus` operation
only accepts numeric types. It is a more complicated problem, and IMO out of
the scope of this issue. We can open a new issue to discuss this problem
separately, and focus on literal handling within this issue.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
