I would imagine this problem will appear when using one dialect or manual construct Rels and later try to do RelToSql to BigQuery.
If directly parse from BigQuery by a way there shouldn't be a problem. -Rui On Tue, Oct 22, 2019 at 10:46 AM Julian Hyde <jh...@apache.org> wrote: > 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 <amaliu...@apache.org> 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 > >
