calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ashutosh Chauhan <hashut...@apache.org>
Subject Re: type coercion
Date Tue, 16 Sep 2014 22:55:42 GMT
My purpose would be served if  that method is changed to pass true for
coercion, which I think it should do since it exists in SqlTypeFactory.
So, to me it seems current Optiq implementation is buggy. Any objection for
that patch?

On Tue, Sep 16, 2014 at 3:49 PM, Julian Hyde <julianhyde@gmail.com> wrote:

> For most SQL types you can cast either way, so you won't get a definitive
> answer to "which is less restrictive, double or varchar?" if you use
> whether you can cast as your criterion.
>
> Hive's semantics are different than Optiq's but still reasonable. There
> isn't a method that gives your required semantics but you are welcome to
> add one.
>
> Julian
>
>
> On Sep 16, 2014, at 3:36 PM, Ashutosh Chauhan <hashutosh@apache.org>
> wrote:
>
> > In Hive, for a union query which includes double from one subq and
> varchar
> > from other subq, we are trying to find common-type by doing :
> > typeFactory.leastRestrictive(types); If coercion was allowed in this
> method
> > chain we would have gotten a common type. But, in current implementation
> it
> > returns null.
> > Should we be using some other method instead of leastRestrictive() ?
> >
> > On Tue, Sep 16, 2014 at 3:29 PM, Julian Hyde <julianhyde@gmail.com>
> wrote:
> >
> >> The method name "leastRestrictiveByCast" does make it look that way. I
> do
> >> not recall why the method has that name. However, "leastRestrictive" is
> >> used in places where casts are not involved, and coercion should not
> occur.
> >>
> >> For instance, if I change those two 'false' values to 'true', Optiq's
> >> validator allows
> >>
> >>  values (1), ('a')
> >>
> >> and
> >>
> >>  select * from emp where deptno in (1, 'a')
> >>
> >> as valid whereas it should give an error.
> >>
> >> Can you give a use case where the current behavior is wrong?
> >>
> >> Julian
> >>
> >> On Sep 16, 2014, at 3:14 PM, Ashutosh Chauhan <hashutosh@apache.org>
> >> wrote:
> >>
> >>> SqlTypeFactoryImpl::leastRestrictive() calls leastRestrictiveByCast()
> >> which
> >>> calls sqlTypeUtil.canCastFrom(type, resultType, false). Last boolean
> >>> argument is about type coercion. Since, its called from
> >> SqlTypeFactoryImpl,
> >>> I expected coercion should have been allowed here and canCastFrom()
> >> should
> >>> have been called with true, atleast thats what comment of canCastFrom()
> >>> method seems to suggest. Is this a bug or am I missing something here?
> >>>
> >>> Thanks,
> >>> Ashutosh
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message