From dev-return-362-apmail-optiq-dev-archive=optiq.apache.org@optiq.incubator.apache.org Tue Sep 16 23:07:33 2014 Return-Path: X-Original-To: apmail-optiq-dev-archive@minotaur.apache.org Delivered-To: apmail-optiq-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5CDE4116E4 for ; Tue, 16 Sep 2014 23:07:33 +0000 (UTC) Received: (qmail 97398 invoked by uid 500); 16 Sep 2014 23:07:33 -0000 Delivered-To: apmail-optiq-dev-archive@optiq.apache.org Received: (qmail 97368 invoked by uid 500); 16 Sep 2014 23:07:33 -0000 Mailing-List: contact dev-help@optiq.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@optiq.incubator.apache.org Delivered-To: mailing list dev@optiq.incubator.apache.org Received: (qmail 97357 invoked by uid 99); 16 Sep 2014 23:07:33 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Sep 2014 23:07:33 +0000 X-ASF-Spam-Status: No, hits=-1998.5 required=5.0 tests=ALL_TRUSTED,HTML_MESSAGE,RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.3] (HELO mail.apache.org) (140.211.11.3) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 16 Sep 2014 23:07:09 +0000 Received: (qmail 97018 invoked by uid 99); 16 Sep 2014 23:07:06 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Sep 2014 23:07:06 +0000 Received: from localhost (HELO mail-la0-f51.google.com) (127.0.0.1) (smtp-auth username hashutosh, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Sep 2014 23:07:06 +0000 Received: by mail-la0-f51.google.com with SMTP id gi9so746842lab.38 for ; Tue, 16 Sep 2014 16:07:04 -0700 (PDT) X-Received: by 10.152.2.41 with SMTP id 9mr15213728lar.79.1410908824781; Tue, 16 Sep 2014 16:07:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.208.201 with HTTP; Tue, 16 Sep 2014 16:06:44 -0700 (PDT) In-Reply-To: References: <808847E0-A0E9-48DD-93F3-400D9653EADE@gmail.com> <0EF98C3B-E75E-49F4-BCCC-DF39E5B3E406@gmail.com> From: Ashutosh Chauhan Date: Tue, 16 Sep 2014 16:06:44 -0700 Message-ID: Subject: Re: type coercion To: dev Content-Type: multipart/alternative; boundary=089e013c62584fcaed050336cfa4 X-Virus-Checked: Checked by ClamAV on apache.org --089e013c62584fcaed050336cfa4 Content-Type: text/plain; charset=ISO-8859-1 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 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 > 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 > 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 > >> 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 > >> 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 > >>>> 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 > >>>> > >>>> > >> > >> > > --089e013c62584fcaed050336cfa4--