I agree that a separate planner rule is better. Besides, if you are
constructing the optimizing rules
by yourself in your project, you can avoid this by not adding
`FilterTableScanRule` and
`ProjectTableScanRule`.
Pranav,
there is a doc[1] about how to contribute to Calcite.
[1] https://calcite.a
Agree with Hyde, there are many problems when converting a physical
RelNode directly to SQL. For example,
https://issues.apache.org/jira/browse/CALCITE-2915
In my project, I have an object holding Logical RelNode and Physical
RelNode. When I want to convert sql, I can use Logical RelNode. I hop
Agreed. Aliases-in-where (enabled by a compliance flag) is a valid feature
request but you’d have to fully define the semantics.
Julian
> On Aug 19, 2022, at 22:46, Jiajun Xie wrote:
>
> Hi, Broeder:
> There's a tricky situation: alias may be the same as column name. Some
> users often make m
It doesn’t seem quite right to convert a physical RelNode directly to SQL. It’s
probably better to map it back to logical RelNode(s) first.
I don’t know whether we have the software to do that mapping. If we don’t,
consider using planner rules. They’re often the right way in Calcite.
Julian
Hi Bencaho,
Thank you very much for your reply. Could you please tell me the procedure
to create this issue on JIRA?
Thanks & Regards,
Pranav
On Fri, Aug 19, 2022 at 11:13 PM Benchao Li wrote:
> Pranav,
>
> This is a good question. To me, I would take this as a bug, and we could
> improve the
>
Hi benchao,
I want to fix the bug, can I log a jira issue?
On Sat, 20 Aug 2022 at 11:13, Benchao Li wrote:
> Pranav,
>
> This is a good question. To me, I would take this as a bug, and we could
> improve the
> RelToSqlConverter to treat BindableTableScan specially.
> Could you please help log
