I can share the couple of lines I'm trying for that step, although away
from the code at the moment so can't share immediately.
Regards
Andrew
On Fri, 19 Apr 2019, 21:01 Mark Pasterkamp,
wrote:
> Dear Andrew,
>
> I would like to do something similar like you are doing and I was wondering
>
Dear Andrew,
I would like to do something similar like you are doing and I was wondering
how you were able to transform the relnode using the planner with the
traitset, would you mind sharing those lines of code with me?
Also, something which might interest you is the following example:
Thanks for the pointers.
I've been able to get an early version of what I was looking do working
based looking at CalcitePrepareImpl and some of the examples in
https://medium.com/@mpathirage/query-planning-with-apache-calcite-part-1-fe957b011c36
.
Essentially my code is currently:
a) Creating
Hi Andrew,
My feeling is that maybe what you actually need is the util class
RelToSqlConverter[1]. But if you are using JdbcAdapter, it does not always
translate the whole SQL you executed as you want. For example in this case[2],
the logical plan is only partially pushed down to the source
Thanks. To try and illustrate a little more - I have users creating ad-hoc
SQL that provides the data they want, but may not be written optimally.
I'd like to be able to use Calcite in some form to accept a SQL string
from them and return an improved / optimised SQL string.
For my use case,
Andrew, I’m not very sure if I got your idea right.
Do you want a promoted `Sql` compared to the original ? Then you should
transform Calcite’s RelNodes tree to sql, but Calcite do not support this yet,
The SqlNode unparse to sql is actually supported.
It is not that equivalent for RelNodes
I'm interested in using Calcite in a "no execute" mode that would
effectively return the optimized SQL but not actually execute it. The
intention would be to leverage a) the query planning / optimization b) the
support for outputting different SQL dialects.
I can see some Tests (e.g.
