Actually, in Oracle, at least the last time I was working on it, if you divided
an int column by an int column, you got an int result which, if I remember
correctly, was truncated.
For people who write SQL, this is a fairly well known issue that we confront,
and solve using the solution
I checked both oracle and impala and in both 1/3 is 0.333 and not 0.
I think that SQL writer is not a programmer and he does not care about data
type. He just want to get the correct results. BTW – it is not only constant,
even expression like sum(case when then 1 else 0 end) / count(*)
will
I think it is fairly standard in programming languages for / to mean
integer division when the operands used are integers. Therefore 1/3=0 is
not a surprising result to me; other programming languages I have worked in
give 1/3=0. However if one of the operands to / is a decimal, the result
is
On Thu, 2016-09-22 at 05:39 +, Bulvik, Noam wrote:
We have an app that let user write their own SQL
Um, do they write DROP TABLE statements in there?
Elsevier Limited. Registered Office: The Boulevard, Langford Lane, Kidlington,
Oxford, OX5 1GB, United
Thanks for the workaround , but it is not a solution for our case. We have an
app that let user write their own SQL and we can’t tell them to always write
int numbers as xxx.0
I created https://issues.apache.org/jira/browse/PHOENIX-3312
Regards,
Noam
From: James Taylor
Adding some more workaround , if you are working on column:-
select cast(col_int1 as decimal)/col_int2;
select col_int1*1.0/3;
On Wed, Sep 21, 2016 at 8:33 PM, James Taylor
wrote:
> Hi Noam,
> Please file a JIRA. As a workaround, you can do SELECT 1.0/3.
> Thanks,
>
Hi Noam,
Please file a JIRA. As a workaround, you can do SELECT 1.0/3.
Thanks,
James
On Wed, Sep 21, 2016 at 12:48 AM, Bulvik, Noam
wrote:
> Hi,
>
>
>
> When I do something like select 1/3 from the result will be
> integer value (0) and not double or alike(0.33….). Is