The reason I ignored CAST is because Druid's type system and expression language are so different than Calcite's I feared we wouldn't be able to push anything down. However, maybe a safe compromise is to push down monotonic casts; see my comments on CALCITE-1618.

You are right Julian Hyde, when I started working on it, I realized it is too restrictive to avoid pushing all CASTs. Monotonic in this case does not seem to serve our purpose.

I have created https://github.com/apache/calcite/pull/370, where I basically fix this issue by only pushing the most common cases that we know that are correct; there are no changes in the results for DruidAdapterIT tests, which seems a good starting point. Could you take a look?

We can create a follow-up to extend this logic and consider more possible cases (in particular I am thinking about numeric types).

I see that you check whether you can push

"where \"product_id\" BETWEEN '1500' AND '1502'\n"

That's fine, but can you add a test case to make sure that

"where \"product_id\" BETWEEN 800 AND 1502\n"

does the right thing. (I'm not sure what is the right thing if product_id is character and 800 and 1502 are integer; can you please check.) If we push and the semantics change from numeric comparison to character comparison, then we'll be giving the wrong results.

Pushed in http://git-wip-us.apache.org/repos/asf/calcite/commit/a07c742.

Thanks Julian Hyde. I have added the new test case. Initially it was not pushed as the comparison was lexicographic instead of alphanumeric. However, there is a property in Druid that we were not setting that allows you to have alphanumeric comparison for bounded filters. I adapted the code to set that property properly.

And further fix up in http://git-wip-us.apache.org/repos/asf/calcite/commit/fdf017aa.

Resolved in release 1.12.0 (2017-03-24).