maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

Hi, Holyfoot!

On Sep 26, Sergei Golubchik wrote:
> Hi, Holyfoot!
> 
> On Sep 24, holyfoot@xxxxxxxxxxxx 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