Re: bk commit into 5.0 tree (davi:1.2591) BUG#33851

[Konstantin Osipov]

* Davi Arnaut <davi@stripped> [08/02/28 06:08]:
> ChangeSet@stripped, 2008-02-27 23:59:18-03:00, davi@stripped +9 -0
>   Bug#33851 Passing UNSIGNED param to EXECUTE returns ERROR 1210
>   
>   The problem is that passing anything other than a integer to a limit
>   clause in a prepared statement would fail. This limitation was introduced
>   to avoid replication problems (e.g: replicating the statement with a
>   string argument would cause a parse failure in the slave).
>   
>   The solution is to convert arguments to the limit clause to a integer
>   value and use this converted value when persisting the query to the log.

I agree with the idea of the change, but I think we should not 
change the code that will never execute just to accommodate the
introduced concept of "strict_type" (i.e. changes in cases of REAL_RESULT and
STRING_RESULT are not necessary).

The only possible "strict type" is "integer", and that's all we need
to care about.

I would leave the old code intact, except add something like this:

if (inside_limit_clause && entry->result_type != INTEGER_RESULT)
{
  bool unused;

  /** Convert the user variable to integer */
  set_int(entry->val_int(&unused), MY_INT64_NUM_DECIMAL_DIGITS);
  item_type= Item::INT_ITEM;
  DBUG_VOID_RETURN;
}

Besides, there is a bug in the current code with a negative
integer value:


mysql> prepare stmt from "select * from t1 limit ?";
Query OK, 0 rows affected (0.02 sec)
Statement prepared

mysql> set @var=-1;
Query OK, 0 rows affected (0.00 sec)

mysql> execute stmt using @var;
Empty set (0.00 sec)

mysql> select * from mysql.general_log where command_type like 'Execute'\G
*************************** 1. row ***************************
  event_time: 2008-02-28 12:14:57
   user_host: root[root] @ localhost []
   thread_id: 2
   server_id: 1
command_type: Execute
    argument: select * from t1 limit -1
1 row in set (0.00 sec)

mysql> select * from t1 limit -1;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use near '-1' at line 1

Please add this test case to the test suite.

-- 
-- Konstantin Osipov              Software Developer, Moscow, Russia
-- MySQL AB, www.mysql.com   The best DATABASE COMPANY in the GALAXY