Develop a standard for spelling all MySQL server command-line options, server variables, and status variables. Hyphen '-' or underscore '_' ---------------------------- Currently, * Options can contain either U+002D '-' or U+005F '_'. They are treated as the same thing, for example one can enter "--skip_networking" or "--skip_networking". They're the same. * Variable names cannot contain '-'. For example @@binlog-cache-size is not a legal name and @@`binlog-cache-size` is an "Unknown system variable". Jonathan Miller says: Either all dashes or all underlined, but should not be both or a mix. Sergei Golubchik says: Prefer '-' for options. Peter Gulutzan says: Prefer '_' for options. Either way, the effect on the server is small, just fix BUG#34635. The documentation should use the preferred (canonical) form always, and explain that the alternate form is acceptable. Displays, e.g. mysqld --help, should show the canonical form always. UPPER CASE, lower case, or Capitalized -------------------------------------- Currently, * Options are always case sensitive and shown in lower case e.g. --basedir * Server variables are case insensitive and shown in lower case e.g. @@basedir * Status variables are case insensitive and shown in lower case except for the first letter (or all upper case in information_schema) e.g. Aborted_clients Jonathan Miller says: Either all uppercase or all lowercase, but should not be both or a mix. ("All uppercase" might imply: allow case insensitive options for a while e.g. both "mysqld --SKIP_NETWORKING" or "mysqld --skip-networking", but deprecate lower case.) Sergei Golubchik says: (apparently) Depends on type. It's primarily a documentation issue. Peter Gulutzan says: Depends on type. Show status vars in a separate table. Deciding -------- Jonathan Miller says: "There will be issue with backwards compatibility ... Architecture Board to develop and publish standards." Peter Gulutzan says: "I'm dubious." Jonathan Miller says: "I would hope that Architecture Board would see this as an issue that concerns how the product is precived in the world of enterprise. And it make me feel bad when the Architecture Board "doubtful" that it will be addressed." Jonathan Miller says: "Server QA to ensure all current options and variables follow this standard." Peter Gulutzan says: "Those people can't control what people dump in." Jonathan Miller says: "No they can not. But they can open a bug report!" Jonathan Miller says: "Server Dev to [deprecate] any option or variables in future versions that do not follow standard." Peter Gulutzan says: "I don't think it matters if we deprecate or not." Other ----- There is no proposal affecting options for mysql client or utilities. References ---------- MySQL Reference Manual, 5.1.1. "Option and Variable Reference", http://dev.mysql.com/doc/refman/6.0/en/mysqld-option-tables.html BUG#34599 (submitted by Jonathan Miller) "MySQLD Option and Variable Reference need to be consistent in formatting!" BUG#34635 (submitted by Sergei Golubchik) "my_long_options in mysqld.cc contains duplicate entries"