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 23:06:44 GMT
Explicit cast is what we are doing to be compliant with Optiq's strict type
system. While doing this explicit cast, we need to find which types we cast
to. So, for that we call this method and then it says null. If Optiq forces
me to explicitly insert cast, it should atleast tell me whats the type I
should cast to?

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

> But when you're bringing together two types in the SELECT clauses of a
> UNION, you are not casting. The coercion that can happen implicitly is
> weaker than the coercion that can happen explicitly.
>
> Are you saying that Optiq is wrong to reject, say,
>
>   SELECT 1 FROM t1 UNION SELECT 'a' FROM t2
>
> because if you change those two false values to true, it will start
> accepting it as valid. (Try it. About 12 Optiq unit tests fail.)
>
> Hive is welcome to its more relaxed type conversion semantics, and we can
> accommodate it, but I don't want to change Optiq's.
>
> Julian
>
> On Sep 16, 2014, at 3:55 PM, Ashutosh Chauhan <hashutosh@apache.org>
> wrote:
>
> > 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