maria-discuss team mailing list archive

[Reindl Harald <h.reindl@xxxxxxxxxxxxx>]

Am 02.09.19 um 20:20 schrieb Marko Mäkelä:
> On Mon, Sep 2, 2019 at 8:48 PM Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
>> and yes, i assumed that a core developer other than you would look at
>> that startup log, came to the conslusion "indeed, no warning there"
>> and while read the few lines "indeed, the latest 10.2 version"
> 
> You are right that a warning should be issued for deprecated variables
> if any value was specified in the configuration file or by a command
> line option.
> 
> Unfortunately, I am not aware how a storage engine could distinguish
> the compile-time default value from a user-specified identical value.
> That is why InnoDB did not issue the deprecation warning for you.
> Maybe you can submit a fix that would address this deficiency?

sadly i am not a C/C++ delevoper but i would expect it to be as simple
as two simple *global* lists

$known_options = ['innodb_support_xa', 'performance-schema=0', ...]
$deprecated_options ['innodb_support_xa', ....]

-DPLUGIN_PARTITION=NO, -DPLUGIN_PERFSCHEMA=NO where broken in multiple
point releases the past years and everytime one decided "well, then
disable that build option and use the config option to disable it"
leaded later in "oh fuck, now the the build was fixed it no longer
starts because of the now unknown option"

a simple lookup in "known_options" and react with a generic warning that
this option is not supported in the current build instead refuse to
start and refuse only when a total unknownm option appears would have
safed a lot of headache