PS Here’s why we should focus on the SQL-to-JDBC example: it is concrete. If
get it right, I’m sure the other adapters will benefit. We need to be sure not
to over-fit the internal representation to SQL semantics (e.g. SQL’s IN allows
composite values, e.g. “(x, y) IN ((1, 2), (3, 4))”, has a
Yes, the other adapters need to write their own converters, specific to their
target language. DB languages tend to be divergent in how they represent
“column in (constant1, …, constantN)”[1][2], so this makes sense. Of course
they can borrow/share code with the JDBC adapter.
Julian
[1]
Hi Julian,
Thanks for your reply. I have a question
… where t is a table based on a JDBC data source …
Do we agree on that goal?
Does that mean that each of adapters (Elastic, Geode, Mongo etc.) have to
implement their own version of converters (similar to RexToSqlConverter) ?
If it is a flat
Convert SqlInOperator to In-Expression :
https://issues.apache.org/jira/browse/CALCITE-2630
Related. full table scans and subQueryThreshold.
https://lists.apache.org/thread.html/1a25c956262633f8ef0d224ed76400761f6797c494a21796579eb4f2@%3Cdev.calcite.apache.org%3E
On Tue, Nov 20, 2018 at 12:08
I recall contributing to some other conversations about large IN lists over the
past few months. Before we jump into a discussion, can you locate those
threads? Also, if there is not a JIRA case, can you please create one?
Julian
> On Nov 20, 2018, at 8:23 AM, Mykola Zerniuk
> wrote:
>
>
Dear Calcite Administrators,
my name is Mykola, software engineer from Ukraine.
I had an issue with Calcite IN operator handling.
Here is my previous email to you:
