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: [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]
