Option prefixes deprecated

MySQL 5.6.13 was released earlier this week, and in that release (as well as 5.5.33) the ability to use unique option prefixes was deprecated.  This is fully removed from MySQL 5.7, and I thought it might be useful to amplify the change log notes on why this was done:

Previously, program options could be specified in full or as any unambiguous prefix. For example, the --compress option could be given to mysqldump as --compr, but not as --comp because the latter is ambiguous. Option prefixes now are deprecated. They can cause problems when new options are implemented for programs. A prefix that is currently unambiguous might become ambiguous in the future. If an unambiguous prefix is given, a warning now occurs to provide feedback. For example:

Warning: Using unique option prefix compr instead of compress is
deprecated and will be removed in a future release. Please use the
full name instead.

Option prefixes are no longer supported in MySQL 5.7; only full options are accepted. (Bug #16996656)

I’m not sure the rationale for originally supporting unique option prefixes, but it likely was meant to allow people to use easy-to-remember (and type) shorter versions of option names.  The problem is that any option prefix that works with a certain version today may not work tomorrow, as new options are added which may conflict with a given prefix.  That means that with any new release, programs (including mysqld) might fail to start due to an option prefix which used to work suddenly becoming ambiguous with the introduction of a new option.  It’s not exactly unheard of to add new server options in maintenance releases, while plugins can add new options without even upgrading MySQL.  It seemed prudent to deprecate and remove this functionality rather than allow potential conflicts which would adversely affect users randomly, if they use option prefixes.

The most notable area where this change will affect people is in client use, where use of certain prefixes may be common to avoid keystrokes.  For example:

[oracle@oraclelinux6 mysql-56]$ bin/mysql -uroot --sock=/path/to/mysql.sock
Warning: Using unique option prefix sock instead of socket is deprecated and
will be removed in a future release. Please use the full name instead.
Welcome to the MySQL monitor.  Commands end with ; or \g.

The decision to add deprecation warnings in 5.5 and 5.6 was made to give interactive users visibility to the upcoming removal of this support. For users who leverage option prefixes in scripts or batch files today, and will be adversely affected by the addition of the deprecation warning, we’re hoping to catch all possible affected users at once rather than continue to let users be affected indiscriminately as new options are added in future releases, breaking scripts with random upgrades.

Obviously, the best solution for batch files is to reference an options file with the full option name.  Note that the deprecation warning (and future support removal) applies to prefix usage in options files, as well as command-line options:


[oracle@oraclelinux6 mysql-56]$ cat test.cnf 

[oracle@oraclelinux6 mysql-56]$ bin/mysql --defaults-file=test.cnf --user=root
Warning: Using unique option prefix sock instead of socket is deprecated and 
will be removed in a future release. Please use the full name instead.
Welcome to the MySQL monitor.  Commands end with ; or \g.

By the way, if you like to use “sock” as a prefix for the socket as shown in the above examples, you have an additional option: mysql_config_editor can store socket information:

[oracle@oraclelinux6 mysql-56]$ bin/mysql_config_editor set --login-path=sock \
[oracle@oraclelinux6 mysql-56]$ bin/mysql -uroot
ERROR 2002 (HY000): Can't connect to local MySQL server 
through socket '/tmp/mysql.sock' (2)

[oracle@oraclelinux6 mysql-56]$ bin/mysql --login-path=sock -uroot
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.6.13-enterprise-commercial-advanced MySQL Enterprise 
Server - Advanced Edition (Commercial)

If you use unique options prefixes in options files or batch scripts, please take the time to fix this now before support for this is completely removed in 5.7. Hopefully you can understand how the legacy behavior can lead to deployment-specific problems we can’t anticipate, and the reason behind the deprecation warnings. For those (hopefully very few) who are truly inconvenienced by client deprecation warnings, please consider keeping 5.6.12 or earlier clients, where the deprecation warning doesn’t exist until you can use full option names or options files.

5 thoughts on “Option prefixes deprecated

    1. Hi Jesper,

      That bug report is actually reported against the internal Oracle system, meaning only Oracle support customers can access it (the best way to tell is that any bug ID’s with 8 or more digits are Oracle identifiers). There’s nothing meaningful in the actual internal bug report – it just tracks the implementation of the decision to deprecate rather than the decision-making process itself. This blog post was meant to communicate the reasoning behind that decision – amplifying the change log notes and supplementing the bug report.

  1. One thing worth emphasising is that it is only option prefixes such as –sock and –key-buffer that is being deprecated.

    Single letter options such as -u, -P, and -h are unaffected.

  2. The reason to support option prefixes is simply that GNU getopt_long() supports it and all option parsers somehow copy that behavior.

    IMHO this is a nice feature and I don’t share the opinion that there would be a problem with new options introduced by a new version of a program. An option can only change from valid to ambiguous which will make the new version return a very clear error. The same happens with unabbreviated options as well – they will be removed or incompatibly renamed (think table_cache vs. table_open_cache). Constant adoption is needed anyway.

    This doesn’t mean that I encourage people to use abbreviated options in long lived scripts. Ad hoc command lines are different, but in a script that may be in production for years and shall run unattended, it’s better to be defensive and use unabbreviated option names only.

    PS: that captcha sucks

    1. Hi Axel,

      The point is that a change that causes a valid options to become ambiguous will cause programs to fail, and that this can happen with any new release (or even any new plugin). The problem is less the error (which I agree is clearly articulated) and more that the risk of breakage is difficult to mitigate or assess, and we’ve seen that before with unattended/batch programs.

      And yes, the captcha sucks, sorry! It does prevent much spam, but I’m open to suggestions on better captcha plugins for WordPress.

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.