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:28:43 GMT
We can't use ANY, because on the way back from Optiq tree to Hive tree,
type information will be lost. I guess you are saying if there doesnt exist
a restrictive type, than its upto the user to pick one. I was expecting
same thing to happen by calling that method and if that method allows
coercion (as I argued above because of where it is housed) it would have
worked.

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

> In your opinion, which is less restrictive: varchar or double?
>
> According to the SQL type system (not just Optiq's implementation of it),
> the answer is neither. Neither can convert to the other, without an
> explicit cast.
>
> What does Hive do today? Or does the question not arise, because it
> doesn't use strict types?
>
> For your purposes -- having a type to convert them both to -- I think the
> ANY type might be your savior. If leastRestrictive returns null, try using
> ANY. Any type (pardon the pun) can convert to ANY. That might satisfy
> Optiq's type system enough to build RelNodes and do the optimization.
>
> Julian
>
>
> On Sep 16, 2014, at 4:06 PM, Ashutosh Chauhan <hashutosh@apache.org>
> wrote:
>
> > 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