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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > >> 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 <[email protected]> > >> 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 <[email protected]> > >>>> 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 <[email protected]> > >>>> 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 <[email protected] > > > >>>>>> 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 > >>>>>> > >>>>>> > >>>> > >>>> > >> > >> > >
