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) _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
