I think that the problems you raise are solvable.
*
I want to point out that in the current Calcite parser any literal with
exponent (e.g., 5e0) is parsed as an approximate numeric literal, i.e., a
literal with type Double. That's the APPROX_NUMERIC_LITERAL grammar production.
The actual val
Mihai,
I accept your point that literals may have values that are binary floating
point. (As we discussed, they are impossible to create via SQL, but may be
created via constant reduction.)
But I still have a concern that developers will accidentally create numeric
literals with double values.
The TableFunctionScan indeed seems to fit exactly the "FunctionJoin"
use-case. If the TableFunctionScan alone cannot fulfil your use-case
then I am pretty sure that a combination of Correlate +
TableFunctionScan should do the trick. The examples in the Calcite
codebase are a bit scarce but you can
Ulrich Kramer created CALCITE-6236:
--
Summary: EnumerableBatchNestedLoopJoin uses wrong row count for
cost calculation
Key: CALCITE-6236
URL: https://issues.apache.org/jira/browse/CALCITE-6236
Project
‘Function join’ sounds similar to ‘CROSS APPLY’ - for each row on the left,
call a function to generate a list of rows on the right. Is that how you see it?
If so, there are some beautiful parallels between CROSS APPLY and lateral join;
for example, they can both be de-correlated. See [1] and la
