On Jul 18, 2007, at 5:42 AM, Allan Odgaard wrote:
Your fix (for the ideal setup) breaks this -- if the majority of servers out there as the proper encoding set, it seems we should take the fix, otherwise I think a more practical solution would be to ensure that we set the same encoding as the server use, and let the user configure a per-connection encoding, which we then convert to ourself (I believe this is what CocoaMySQL does).
Unfortunately, I think you're right to expect things to break. I know about this for the same reason as I've flushed out a fair number of bugs making things pure utf8, including a few
The naive patch does meet the "Everything is utf8" goal but can't help with improperly encoded data. One approach might be to "SELECT @@character_set_client, @@character_set_database" and require the user to specify the desired encoding if they don't match since that's probably a reliable check for encoding problems.
One other approach involves something I've been thinking about for awhile: mysql has an existing way to specify the database options - the .my.cnf file. I originally was thinking about modifying the code to use the default username/password from that file if the user hadn't configured a value and it occurs to me that we could check for "default-character-set=utf8" in the mysql section of that file, probably in conjunction with either hostname=localhost or the existence of --host/--database options which match the target database.
Chris