davisp opened a new issue, #12655:
URL: https://github.com/apache/datafusion/issues/12655

   ### Describe the bug
   
   I ran across a query where `select * from foo where col < 1.3` returns 
values rendered as `1.3`. My guess is that this is either a subtle parsing 
difference or possibly the result of a differently ordered type cast. If you 
change the column type from `float` to `double` the issue no longer occurs.
   
   Also, just to preempt anyone jumping to floating point values are 
approximations, I'm fully aware. I know that this issue is likely caused either 
by the miniscule difference between `f32::from_str` and `f64::from_str` or `f32 
as f64` vs `f64 as f32` or some combination thereof. However, given that this 
is all one parser, it feels like a bug that we've parsed two different values 
for the same string.
   
   ### To Reproduce
   
   ```
   DataFusion CLI v42.0.0
   > create table test(col float);
   0 row(s) fetched.
   Elapsed 0.008 seconds.
   
   > insert into test values (1.1), (1.2), (1.3), (1.4), (1.5);
   +-------+
   | count |
   +-------+
   | 5     |
   +-------+
   1 row(s) fetched.
   Elapsed 0.007 seconds.
   
   > select * from test where col > 1.3;
   +-----+
   | col |
   +-----+
   | 1.4 |
   | 1.5 |
   +-----+
   2 row(s) fetched.
   Elapsed 0.004 seconds.
   
   > select * from test where col < 1.3
   ;
   +-----+
   | col |
   +-----+
   | 1.1 |
   | 1.2 |
   | 1.3 |
   +-----+
   3 row(s) fetched.
   Elapsed 0.002 seconds.
   ```
   
   ### Expected behavior
   
   I would expect that `1.3 == 1.3`.
   
   ### Additional context
   
   _No response_


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to