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)
I stand corrected. For now, only the default collation can be used. That will be fixed. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
