Patch for Bug#21818 (Return value of ROW_COUNT() is incorrect

for ALTER TABLE, LOAD DATA).

ROW_COUNT is now assigned according to the following rules:

  - In my_ok():
    - for DML statements: to the number of affected rows;
    - for DDL statements: to 0.

  - In my_eof(): to -1 to indicate that there was a result set.

    We derive this semantics from the JDBC specification, where int
    java.sql.Statement.getUpdateCount() is defined to (sic) "return the
    current result as an update count; if the result is a ResultSet
    object or there are no more results, -1 is returned".

  - In my_error(): to -1 to be compatible with the MySQL C API and
    MySQL ODBC driver.

  - For SIGNAL statements: to 0 per WL#2110 specification. Zero is used
    since that's the "default" value of ROW_COUNT in the diagnostics area.

sql/sql_signal.cc

@@ -458,8 +458,20 @@ bool Signal_statement::execute(THD *thd)
 
   DBUG_ENTER("Signal_statement::execute");
 
+  /*
+    WL#2110 SIGNAL specification says:
+
+      When SIGNAL is executed, it has five effects, in the following order:
+
+        (1) First, the diagnostics area is completely cleared. So if the
+        SIGNAL is in a DECLARE HANDLER then any pending errors or warnings
+        are gone. So is 'row count'.
+
+    This has roots in the SQL standard specification for SIGNAL.
+  */
+
   thd->stmt_da->reset_diagnostics_area();
-  thd->row_count_func= 0;
+  thd->set_row_count_func(0);
   thd->warning_info->clear_warning_info(thd->query_id);
 
   result= raise_condition(thd, &cond);