On Mon, 2007-05-14 at 09:33 +0200, Peter Rabbitson wrote: > Paul J Stevens wrote: > > Aaron Stone wrote: > >> We issue only a "SET NAMES 'encoding'" without the COLLATION argument, > >> so at the moment we fall onto whatever default the database has, but... > >> > >> Unless Paul changed any queries with the major utf8 cleanup today, the > >> database collation doesn't matter because we don't ask the database to > >> do any sorting on utf8 columns; all of the sorting takes place on the > >> DBMail side in concert with GMime. > > > > No queries were changed. The cleanup wasn't that major actually. But the > > collation does matter because in the IMAP SORT code we do rely on the > > database > > for collation and sorting. It seems to me that's a good thing actually, > > because > > it allows us to let the database handle this issue. > > > > We should probably change the table definitions to use UTF8 encoding and > > utf8_unicode_ci. DBAs can ofcourse change collation per table or per column > > as > > desired. Dbmail doesn't really care at the moment. > > Erm... It does. It detects collation mismatches just as encoding > mismatches. See the thread titled 'mysql collation for dbmail'. Or it > might be that I am using an antiquated dbmail version? (the latest > 2.2.5-0rc1 debian package)
It's equally possible that I was being too pedantic about looking for anything resembling an encoding, and the best fix is to remove the collation check. I have not looked deeply into these issues recently, so I'm scratching to find out if someone really knows the right thing to do in this situation. Aaron _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
