On Thu, 13 Aug 2009 02:03:43 +0100 Roger Leigh <rleigh@codelibre.net> wrote: > On Wed, Aug 12, 2009 at 11:44:36PM +0200, Harald Braumann wrote: > > On Wed, 12 Aug 2009 13:03:30 +0100 > > Roger Leigh <rleigh@codelibre.net> wrote: > > > > > On Wed, Aug 12, 2009 at 01:18:12PM +0200, Thomas Koch wrote: > > > > I'm not sure, whether a conclusion is already reached. > > > > > > > > 1. apt-get install mysql > > > > 2. enter mysql client > > > > 3. create database test; create table test( test char(10) ); > > > > > > > > Replace mysql with whatever application you like. > > > > > > > > What should be the encoding of database and table test in cases > > > > like the above? > > > > > > > > Currently it's iso-something, discriminating everybody from > > > > other countries. If it would be utf-8 instead, it would have at > > > > least two advantages > > > > > > > > - The clueless user would get a sane default > > > > - utf-8 isn't as discriminating as iso-8859-1 > > > > > > UTF-8 is the sane default choice in this situation, so long as > > > MySQL is capable of handling it. > > > > Is that a real problem? Usually applications that use a SQL DB come > > with some script to set up the schema. If they want UTF-8, they will > > create a table with UTF-8 encoding. I wouldn't change MySQL's > > default without reason, because old scripts might rely on that > > behaviour. > > Those "old scripts" which don't specify an encoding *are already > buggy* due to not saying what they want, implying that the default > (whatever that might be) is fine. Agreed. Still no need to break them on purpose. > There's the possibility that this might cause some problems, but they > are problems in the script, not in MySQL. Keeping using an obsolete > encoding like Latin 1 (or whatever the default currently is) prevents > any breakage, but at the expense of moving to a sane default for the > future. I really don't care too much about the specific case of MySQL, as I hardly ever create or manipulate SQL data by hand. All I was saying and you seem to be saying as well, if I understand you correctly, is that it is the duty of the application that creates and uses SQL tables to specify the encoding, if it cares about it. If the application does that, it will work, no matter what default is specified for MySQL. So this specific case is a non-issue, IMO, and MySQL's default doesn't need to be changed. But if it is, just for the sake of it, then that's fine with me. Some scripts might break, but OK. > > > Those applications, however, should be configured to use UTF-8 by > > default (if they support it) and their DB setup scripts accordingly. > > They should indeed, but if they don't then they need to explicitly > spell out what they *do* support. The should. Cheers, harry
Attachment:
signature.asc
Description: PGP signature