As I look on the schema for MySQL it looks like the order of the statements was changed at some point (maybe during refactoring - to modify multiple columns at once as it improoved performance of table schema modification). As a result those columns were not dropped.

Should we update this schema to make sure that they are dropped?

I'd say yes: to both be consistent and have intended state of the schema.

I've just "recreated" schema for MySQL (on the new database) in version 2.0.0 and upgrade it to version 3.0.0 and problematic fields were removed.

I would say that we have an issue with current version of the database on tigase.org caused by any of the following:

1. manual running of the update due to initial issues with upgrade of the database
2. subsequent upgrades between snapshot builds did not upgrade database properly
3. manual start of previous version of the schema script set version to "stable" so subsequent runs of schema upgrade were not executed

As for point 3. we still have following line there:

call TigSetComponentVersion('message-archiving', '3.0.0');

What we can do?

1. Leave it as it is, as it removes columns properly while running normal upgrade process.
2. Add additional checks to remove those columns

I suppose, that I've manually removed msg_id column as we had some constraint issues and had to fix them on this database, so it is most likely that I've forgot to drop the rest of those columns and condition to drop them is based on existence of msg_id columns.

I'm sorry I haven't made myself more clear - tigase.org database/schema is correct. Cleanly created postgres schema contains those additional fields (indicated in the table in the first message). It seems that the SP from the linked commit is not applied correctly here.

The schema is now fixed.