Comment 6 for bug 337038

Revision history for this message
Padraig O'Sullivan (posulliv) wrote :

Ok, I have every test case that was failing fixed except for 1. The one that's failing is func_group and only fails in 1 instance. It fails with a table and query like this:

drizzle> create table t1 (a int, b int, c int);

and then insert some values which look like:

drizzle> select * from t1;
+------+------+------+
| a | b | c |
+------+------+------+
| 1 | 1 | 1 |
| 1 | 1 | 2 |
| 1 | 1 | 3 |
| 1 | 1 | 3 |
+------+------+------+
4 rows in set (0.00 sec)

Now, if I execute a query with a group by where I group by a fraction as follows (this is the current behavior in trunk):

drizzle> select b/c as v, count(*) from t1 group by v;
+--------+----------+
| v | count(*) |
+--------+----------+
| 0.3333 | 2 |
| 0.5000 | 1 |
| 1.0000 | 1 |
+--------+----------+
3 rows in set (0.01 sec)

drizzle>

With the fix that I have implemented, decimal truncation throws an error in the store_value() method. Thus, the above query now gives a result like:

drizzle> select b/c as v, count(*) from t1 group by v;
+-----------------+----------+
| v | count(*) |
+-----------------+----------+
| 0.5000 | 1 |
| 1.0000 | 1 |
| 9999999999.9999 | 2 |
+-----------------+----------+
3 rows in set (0.00 sec)

drizzle>

If we look at store_value(), we can see what happens here:

  if (warn_if_overflow(my_decimal2binary(E_DEC_FATAL_ERROR & ~E_DEC_OVERFLOW,
                                         decimal_value, ptr, precision, dec)))
  {
    my_decimal buff;
    set_value_on_overflow(&buff, decimal_value->sign());
    my_decimal2binary(E_DEC_FATAL_ERROR, &buff, ptr, precision, dec);
    error= 1;
  }

With the fix for this bug, warn_if_overflow() now returns 1 if truncation occurs (which it did not previously). Thus, if we remove the 3 lines where a value is set after the truncation occurs and just set error to 1, the query will behave as it originally did and the test case will pass. However, I'm wondering what the desired behavior is here? Should this query fail? Is it better to set the truncated value as in the output I gave above?

-Padraig