Hi, Holyfoot! On Sep 26, Sergei Golubchik wrote:
Hi, Holyfoot!
On Sep 24, holyfoot@askmonty.org wrote:
revision-id: 1d92131613770b505fa462b33c1091e00d9475be (mariadb-10.1.7-61-g1d92131) parent(s): e5418942609833edb681d16c4e2705f8c338bfee committer: Alexey Botchkov timestamp: 2015-09-24 14:31:06 +0500 message:
MDEV-4829 BEFORE INSERT triggers dont issue 1406 error. Fixed as it's done in MySQL 5.7. The Strict_error_handler introduced to intercept such states and is activated in the sp_head::execute_trigger() ... +class Strict_error_handler : public Internal_error_handler +{ +protected: + bool handle_condition(THD *thd, + uint sql_errno, + const char* sqlstate, + Sql_condition::enum_warning_level level, + const char* msg, + Sql_condition ** cond_hdl) + { DBUG_ASSERT(FALSE); return 0; } +public: + bool handle_condition_ext(THD *thd, + uint sql_errno, + const char* sqlstate, + Sql_condition::enum_warning_level *level, + const char* msg, + Sql_condition ** cond_hdl);
1. why not to change handle_condition() ? 2. strict mode may change the sql_errno, handle_condition_ext doesn't support it.
Now I think that this is a fundamentally flawed idea. When a warning is changed to an error this affects not only the level, but also the errno, and - that's the difficult part - the error message. And the error handler cannot replace the error message, because it does not have values for all printf parameters that the error message might need. In MySQL they apparently have the mix of the old and new strict-handling, but I would rather avoid it. Such a mix could be allowed short-term, until old code is removed and replaced by the new approach. But here this can never happen, and I'd rather not have the solution that is broken from the start. Regards, Sergei