[GitHub] [druid] hardikbajaj commented on issue #13400: SQL does not properly handle equals between timestamp and string literal

["hardikbajaj (via GitHub)" <gi...@apache.org>]

hardikbajaj commented on issue #13400:
URL: https://github.com/apache/druid/issues/13400#issuecomment-1564829003

   Hey @gianm , I've traced this and this is a calcite issue on this [line](https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/sql2rel/StandardConvertletTable.java#L1137). For `>=` and `<` calcite assigns consistency as `COMPARE`, while for equal to(=) case, it assigns it as `LEAST_RESTRICTIVE`. So what happens is before moving to `LEAST_RESTRICTIVE` case removes non character type literals and only Timestamp is left, so rex node is typecasted as `TIMESTAMP(3)`. While in `=` case, from `VARCHAR` and `TIMESTAMP(3)`, VARCHAR is chosen as least restrictive type and RexNode is typecasted as that. I don't understand this behaviour, but this issue can be fixed here on calcite side.
   I can fix this on druid side also, but what I think is I'll have to parse these three types of timestring to get Epoch Millis value. Do you think this would be a wise thing to do? Or this should be fixed at Calcite side only?
   
   


-- 
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: commits-unsubscribe@druid.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org