Bug #10186 default_character_set_results switch
Submitted: 26 Apr 2005 19:02 Modified: 14 Dec 2010 19:44
Reporter: Csongor Fagyal Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server Severity:S4 (Feature request)
Version:4.1.* OS:Linux (Linux)
Assigned to: CPU Architecture:Any
Triage: D5 (Feature request)

[26 Apr 2005 19:02] Csongor Fagyal
Description:
I don't like in the current behaviour that while the database, all the defaults, the tables the columns are using a specific encoding, still I have to explicitly tell the client what encoding to use (e.g. DBD::mysql)

How to repeat:
Simply install MySQL 4.1.x (I used 4.1.9), use DBD::mysql, set "all possible values" to latin2, and still when reading a latin2 string it gets converted to latin1 when "set character_set_results" is not explicitly set by the client at each connect() call.

Suggested fix:
Add "default_character_set_results", which would result in MySQL handle all client data using the given encoding when the client does not _explicitly_ set a different encoding.

Or character_set_results could have the value of character_set_server (or maybe the character set of the column of the table) when something does not override it.

And maybe the same for "collation" values.
[26 Apr 2005 19:04] Csongor Fagyal
Oooops... I was using Fedora Core 3 with 4.1.11 and RedHat 8 with 4.1.9 (same results).
[13 May 2005 22:09] Csongor Fagyal
I think this might be a duplicate of Bug #9230.
[14 Dec 2010 19:44] Valeriy Kravchuk
Duplicate of Bug #9230.