Paul Rogers created DRILL-6368:
----------------------------------
Summary: "E" operator does not behave as documented "exponent
operator"
Key: DRILL-6368
URL: https://issues.apache.org/jira/browse/DRILL-6368
Project: Apache Drill
Issue Type: Bug
Affects Versions: 1.13.0
Reporter: Paul Rogers
Consider the [opertors|http://drill.apache.org/docs/operators/] page which
lists "E" as an operator:
bq. E Prededence: left exponentiation
This would mean that we can use "E" as our exponentiation operator. Let's try
it:
{noformat}
SELECT 10E3 FROM (VALUES(1));
+----------+
| EXPR$0 |
+----------+
| 10000.0 |
+----------+
{noformat}
It worked! 10^3 is indeed 1000. Wait, what? The result presented above is
10,000. Off by 10x....
Well. What's 10x among friends? Let's try more cases. Let's ensure the operator
is, in fact, left associative:
{noformat}
SELECT 10E3E2 FROM (VALUES(1));
+----------+
| E2 |
+----------+
| 10000.0 |
+----------+
{noformat}
Really? 10,000 ^ 2 is still 10,000?
Let's do some math:
{noformat}
SELECT (5+5)E3 FROM (VALUES(1));
+-----+
| E3 |
+-----+
| 10 |
+-----+
{noformat]
Lessee, 5 + 5 = 10. 10^3 = 1000. But the answer is 10.
Well. As an operator, it can stand alone, right? Just like +? Let's try:
{noformat}
SELECT 10 E 3 FROM (VALUES(1));
Error: PARSE ERROR: Encountered "3" at line 1, column 13.
{noforomat}
Jokes aside, it appears that the "E" symbol only works in the pattern:
{noformat}
number E number
{noformat}
That is, it is part of the scientific notation syntax common in many
programming languages. It appears that the SQL parser is sloppy and kind of
treats E as an operator, in very limited cases, but does not catch cases in
which the usage is invalid.
The requests here are:
1. Change the documentation to not state that "E" is an exponentiation
operator. (It isn't.)
2. Fix the parser so that id does not ignore bogus cases such as those shown
above.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
