Bug #3041 --safe-updates option declaration anomaly
Submitted: 2 Mar 2004 9:57 Modified: 15 Mar 2004 23:18
Reporter: Paul DuBois Email Updates:
Status: Closed Impact on me:
Category:MySQL Server: Command-line Clients Severity:S3 (Non-critical)
Version:all OS:Any (All)
Assigned to: Sergei Glukhov CPU Architecture:Any

[2 Mar 2004 9:57] Paul DuBois
I'll just repeat the relevant email here:

Date: Tue, 2 Mar 2004 18:10:55 +0100
From: Sergei Golubchik <serg@mysql.com>
To: Paul DuBois <paul@mysql.com>
Cc: dev-public@mysql.com
Subject: Re: --safe-updates oddity?


On Feb 29, Paul DuBois wrote:
> I noticed today that --safe-updates/--i-am-a-dummy option for
> mysql is listed in the manual as taking an optional argument:
> @item --safe-updates[=#], --i-am-a-dummy[=#], -U[#]
> Only allow @code{UPDATE} and @code{DELETE} that uses keys. See below for
> more information about this option.  You can reset this option if you have
> it in your @file{my.cnf} file by using @code{--safe-updates=0}.
> I never knew it took an argument, so I figured I'd look in the source
> to see what meaning the value might have.  Indeed the option structures
> in mysql.cc allow an optional argument:
>   {"safe-updates", 'U', "Only allow UPDATE and DELETE that uses keys.",
>    (gptr*) &safe_updates, (gptr*) &safe_updates, 0, GET_BOOL, OPT_ARG, 0, 0,
>    0, 0, 0, 0},
>   {"i-am-a-dummy", 'U', "Synonym for option --safe-updates, -U.",
>    (gptr*) &safe_updates, (gptr*) &safe_updates, 0, GET_BOOL, OPT_ARG, 0, 0,
>    0, 0, 0, 0},
> However, the variable itself is a my_bool type, and the value is only
> tested in if() conditionals, but never otherwise used.
> So it appears to me that the manual should just remove the [=#] from
> the description, and OPT_ARG in mysql.cc should be changed to NO_ARG.
> Is that correct?

Yes, I think so.


How to repeat:
See above.

Suggested fix:
See above for change to mysql.cc.
I'll change the documentation.
[15 Mar 2004 23:18] Sergei Glukhov
Fixed in 4.1