calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <julianh...@gmail.com>
Subject Re: type coercion
Date Tue, 16 Sep 2014 23:01:49 GMT
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
View raw message