walterddr commented on PR #9385:
URL: https://github.com/apache/pinot/pull/9385#issuecomment-1247391278
> Is there any reference available that talks about the restriction on
implicit cast between them? If yes, can you link it to the description section
of this PR?
>
> We might need to carefully monitor the deployment in order to detect any
existing use cases once this PR is merged.
yes I was suggesting either a release note or a backward incompatible
section in the PR but also in Pinot doc.
In terms of the rationale, AFAIK,
- nothing should be implicitly cast in logical plan. what we do NOW is b/c:
- if a function expects `foo(int, long)` then they data type should be
exact
- however many system implements overload `foo(int, int), foo(int, long),
foo(long, long) ...` so it will always find one properly. Pinot doesn't support
these type of operator/function overloading thus we need to provide implicit
cast.
- many logical planner insert explicit CAST operator if the type doesn't
match in user's provided SQL, for example:
- `SELECT intCol + strCol FROM tbl` will result in a
```
LogicalProject(
[+(intCol, CAST(strCol, INT))],
LogicalScan(
tbl,
[intCol, strCol]
)
)
```
so IMO as long as we state clearly in our user-facing implicit cast rule in
doc we are good. I am incline to the following:
- all numeric should have implicit cast and (1) throw exception (2) put
MAX/MIN_VAL, or NaN when overflow
- all DataType sharing the same StorageType should be able to implicitly
cast between (for example JSON / STRING)
- all other should not have default implicit cast rule
-
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
