It’s very similar to https://issues.apache.org/jira/browse/CALCITE-3282 <https://issues.apache.org/jira/browse/CALCITE-3282> and the solution will be the same.
Inside Calcite (e.g. in RexNode format), I suggest that you map BigQuery types onto standard SQL types where possible. For example, BQ’s INT64 should be Calcite’s BIGINT, BQ’s STRING should be VARCHAR. I wish BigQuery in “standard SQL” mode accepted standard SQL types. Julian > On Oct 22, 2019, at 10:23 AM, Rui Wang <[email protected]> wrote: > > Hi community, > > Recently I submitted a patch [1] to have a correct type converting to > BigQuery dialect when there is a CAST in RelToSql. That patch left some > cases unhandled, e.g. INTEGER. The reason is BigQuery does not support > INTEGER or INT32, it only supports INT64. > > So the open question is, in RelToSql, if the Rel does "CAST(x AS > unsupported type)" for a dialect, what should we do? There are two options: > 1. throw an exception. > 2. Try to cast the type to one compatible type in the target dialect. E.g. > INTEGER cast to INT64.If there is no compatible type, throw exception. > > What do you think? Also, for the option 2, if we are in favor of it, what > rules we should follow to does such cast? > > > > [1]: > https://github.com/apache/calcite/commit/30a0dd0a2edebdc08292b7d59988c60ccf754bed > > -Rui
