Peter, > I painstakingly followed the changes from previous amavisd-new > installations to amavisd-new-2.6.0 a while ago. > > I couldn't find any list of changes between 2.6.0 and 2.6.1 except what > was mentioned in the mails on this list. So I sat down and created a diff > between the READMEs of 2.6.0 and 2.6.1. > > The few changes I found were (listed as mysql commands):
> ALTER table msgs CHANGE sid sid integer; > ALTER table msgrcpt CHANGE rid rid integer; This should probably be a 'bigint unsigned', or whatever makes SQL happy (satisfies data type match in FOREIGN KEY). It reflects the following entry from release notes (documentation update): - README.sql-mysql: fixed a SQL data type mismatch between maddr.id (used as a foreign key) and msgs.sid & msgrcpt.rid; they all should be of the same type, either integer unsigned or bigint unsigned; a schema as published in README.sql-mysql could not be built because of a conflict in a data type; reported by Leonardo Rodrigues Magalhães and Zhang Huangbin; > ALTER table msgs CHANGE mail_id mail_id varbinary(12); > ALTER table msgs CHANGE secret_id secret_id varbinary(12); > ALTER table msgs CHANGE content content binary(1); > ALTER table msgs CHANGE quar_type quar_type binary(1); > ALTER table msgs CHANGE quar_loc quar_loc binary(255); > ALTER table msgrcpt CHANGE mail_id mail_id varbinary(12); > ALTER table quarantine CHANGE mail_id mail_id varbinary(12); This looks right, thanks for providing the ALTER commands for changing varchar into varbinary and char into binary. This change to a MySQL database is optional and at the moment not applicable to a more picky PostgreSQL. It refers to this entry in release notes: - README.sql-mysql: changed SQL datatype VARCHAR into VARBINARY for data fields mail_id, secret_id and quar_loc, and CHAR into BINARY for msgs.content and msgs.quar_type to preserve case sensitivity on string comparison operators; suggested by Thomas Gelf; The same change should eventually be done on README.sql-pg too, but as PostgreSQL is more picky than MySQL on matching a field data type to a supplied data value, the change of a data type would need to be reflected in SQL calls in amavisd. This will have to wait until some future version of amavisd-new, having to undergo more testing than I have available before the 2.6.1 release. > If anyone has more experience with mysql, or anyone finds a mistake in > the list above, please let me know. > > I hope this is useful for more people than just me. Useful, thanks. Mark ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ AMaViS-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
