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 > >> > >> > >
