MySQL Bugs: #69997: Please expose skip-character-set-client-handshake as a variable

Bug #69997	Please expose skip-character-set-client-handshake as a variable
Submitted:	12 Aug 2013 15:19	Modified:	15 Aug 2013 22:48
Reporter:	Peter Laursen (Basic Quality Contributor)	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: Options	Severity:	S3 (Non-critical)
Version:	any.	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
The headline should tell. It seems that it is (still) quite common in Russia to have this option set in combination with a non-unicode cyrillic character set as the default server character set. I have now experienced this 5+ times in 1 to 1½ years.

It is extremely confusing to work with a server where this option is set and you don't know. You cannot assume that client users have access to configuration. You can SET NAMES after connection - but it is not alwyas easy to tell that that is what is requried to make a client using another character set (utf8 primarily) work properly.

Docs reference: http://dev.mysql.com/doc/refman/5.0/en/server-options.html#option_mysqld_character-set-cli...

I actually thought I posted this before. But cannot find. So probably I did not!

How to repeat:
SHOW VARIABLES LIKE 'skip-character-set-client-handshake';
.. returns an empty set.

Suggested fix:
Or even better: remove this option! It could have made sense when 4.1 was released for emulating earlier versions' behaviour and application compability, but now I think users should know how to use charset in both server and clients!

I should have posted this link instead:
http://dev.mysql.com/doc/refman/5.6/en/server-options.html#option_mysqld_character-set-cli...
(to tell that the option is still in 5.6)

This reprot http://bugs.mysql.com/bug.php?id=70036 now occurred. Also related to skip-character-set-client-handshake.

Thank you for the bug report.