* 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
