maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

Hi, Sergey!

On Nov 23, Sergey Vojtovich wrote:

> > > diff --git a/storage/maria/ha_maria.cc b/storage/maria/ha_maria.cc
> > > index 2e2aa71..064d759 100644
> > > --- a/storage/maria/ha_maria.cc
> > > +++ b/storage/maria/ha_maria.cc
> > > @@ -256,6 +256,11 @@ static MYSQL_SYSVAR_ULONG(pagecache_file_hash_size, pagecache_file_hash_size,
> > >         512, 128, 16384, 1);
> > >  
> > >  static MYSQL_SYSVAR_SET(recover, maria_recover_options, PLUGIN_VAR_OPCMDARG,
> > > +       "Deprecated and will be removed in a future release. Please use "
> > > +       "--aria-recover-options instead.",
> > > +       NULL, NULL, HA_RECOVER_DEFAULT, &maria_recover_typelib);
> > > +
> > 
> > Why? my_getopt does unambigous prefix matching, so --aria-recover
> > will contnue to work after the rename without any explicit
> > deprecated variables. So this one doesn't do any good.
> > 
> > In fact, this variable has bad effects, without it 'aria-recov' (or
> > any other unambigous prefix of aria-recover) would continue to work,
> > but with this new deprecated variable 'aria-recov' will no longer be
> > unambigous.
> You're right. Two questions:
> - I think MySQL is getting rid of unambiguous prefix matching. I just
> wonder if we plan to do the same?

We might. In 10.1 I've added an option --getopt-prefix-matching and
in mysql-test we use --disable-getopt-prefix-matching. But by default
it's still enabled.

> - If some day we decide to add --aria-recover-something, won't it break
>   --aria-recover?

Yes, of course. That's why 5.7 disabled unambiguous prefix matching and
that's why we have --disable-getopt-prefix-matching.

On the other hand, I don't think we should break aria-recover now just
because we might perhaps eventually break it some day in the future :)

> If the above points aren't worthy, then we definitely should just
> rename this option.

I think "just rename the option" is a good approach here

Regards,
Sergei