Bug#27430 "Crash in subquery code when in PS and table DDL changed after
PREPARE", review fixes: - make the patch follow the specification of WL#4166 and remove the new error that was originally introduced. Now the client never gets an error from reprepare, unless it failed. I.e. even if the statement at hand returns a completely different result set, this is not considered a server error. The C API library, that can not handle this situation, was modified to return a client error. Added additional test coverage. include/errmsg.h: Add a new client side error: now when we automatically reprepare a statement, the new result set may contain a different number of columns. include/mysql_com.h: Add a new server status to be sent to the client if the number of columns in the result set is different. libmysql/errmsg.c: Add a new error message. libmysql/libmysql.c: Make the client library robust against a result set that contains a different number of columns from prepare time. Previously that could never happen, and we simply had an assert. That means in particular that all clients are advised to upgrade with transition to 5.1, if they are using prepared statements C API. Make mysql_stmt_store_result() and mysql_stmt_execute() robust against "broken" statement handles (those that have an error). sql/sql_parse.cc: Clear transient server status flags at start of statement more systematically. sql/share/errmsg.txt: Remove an error that is unused and is not part of any public release. sql/sql_prepare.cc: Instead of returning an error in case the number of result set columns has changed, simply update the client in server status. That will allow modern clients automatically recover from an error. tests/mysql_client_test.c: Add additional coverage to the cases when the number of result set columns changed as a result of reprepare. Cover conversion and truncation of result set columns.
Showing
Please register or sign in to comment