Hi Sergei, I implemented all your suggestions. Could you take a look at updated patch?
Thanks, Sergey On Mon, Nov 25, 2013 at 09:17:02AM +0100, Sergei Golubchik wrote: > Hi, Sergey! > > On Nov 25, Sergey Vojtovich wrote: > > > > > > Do we really want all these do-nothing compatibility options to show up > > > in --help? May be not? The goal of this MDEV was not to fail with an > > > error when starting on mysqld's my.cnf file, no one needs --help for > > > that. > > Agree. I just checked my_getopt sources and couldn't find easy way to hide > > them. Do you have an idea how to hide them properly, or shall I just add > > something like GET_HIDDEN flag? > > GET_xxx normally specifies a type, like GET_DOUBLE. > > In fact, sql_plugin.cc internally uses a convention that NULL in the > comment field means that the option isn't displayed. We could do the > same in my_getopt. > > > > > === modified file 'storage/innobase/handler/ha_innodb.cc' > > > > --- a/storage/innobase/handler/ha_innodb.cc 2013-11-13 21:58:19 > > > > +0000 > > > > +++ b/storage/innobase/handler/ha_innodb.cc 2013-11-20 11:37:53 > > > > +0000 > > > > @@ -15750,6 +15750,12 @@ static MYSQL_SYSVAR_BOOL(purge_stop_now, > > > > PLUGIN_VAR_OPCMDARG, > > > > "Set purge state to STOP", > > > > NULL, purge_stop_now_set, FALSE); > > > > + > > > > +static my_bool innodb_log_checkpoint_now; > > > > +static MYSQL_SYSVAR_BOOL(log_checkpoint_now, innodb_log_checkpoint_now, > > > > + PLUGIN_VAR_OPCMDARG | PLUGIN_VAR_NOSYSVAR, > > > > + "MySQL 5.6 compatibility option. To be implemented in later 10.x > > > > versions.", > > > > + NULL, NULL, FALSE); > > > > #endif /* UNIV_DEBUG */ > > > > > > Why is that (and everything else in ha_innodb.cc) necessary? > > > We'll merge with the latest InnoDB, we will have all its variables. > > Same reason as for the other "to be implemented" options. Do you think there > > is any difference? > > Yes. For other options we need to made a conscious decision to merge the > feature and then actually merge it. We might do it for some options and > might not do it for others, on a case by case basis. > > For InnoDB options we already decided that we will merge latest InnoDB > changes. Thus we know for sure that all these options will be in 10.0.7, > there is no place for "might not" or "case by case". Your changes will > only cause merge conflicts. > > Regards, > Sergei > _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
