You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Rui Wang <am...@apache.org> on 2019/10/22 17:23:10 UTC
type casting or throw exception for unsupported type in SQL dialects
in RelToSql
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
Re: type casting or throw exception for unsupported type in SQL
dialects in RelToSql
Posted by Rui Wang <ru...@google.com.INVALID>.
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 <am...@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
>
>
Re: type casting or throw exception for unsupported type in SQL
dialects in RelToSql
Posted by Julian Hyde <jh...@apache.org>.
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 <am...@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