Incorrect mismatches, particularly regarding MySQL SIGNED INT values

Another example of misreported mismatches (from outline.module):

outline_book
column default_toc_depth:
declared: array('type' => 'int', 'unsigned' => FALSE, 'not null' => TRUE, 'default' => -1)
actual: array('type' => 'int', 'not null' => TRUE, 'default' => -1, 'disp-width' => '11')

outline_node
column toc_depth:
declared: array('type' => 'int', 'unsigned' => FALSE, 'not null' => TRUE, 'default' => 0)
actual: array('type' => 'int', 'not null' => TRUE, 'default' => 0, 'disp-width' => '11')

Similarly, the tables where created with the schema API.

Could some of these be a bug in how it interprets MySQL's information_schema.STATISTICS output, maybe from an internal MySQL change? I'm seeing this with multiple modules, e.g. nodewords_bypath and imagecache.

Issue #402036: migrate_content_sets schema does not match database is a duplicate of this.

There have been posts in the past on Schema throwing mismatches of "unnecessary 'default' => NULL" for mysql
At one point
http://drupal.org/node/256826
a patch was floated. However this patch was against "schema.module 2008-06-17 17:23:19".
The current module for Drupal 6 is "schema.module,v 1.33 2008/05/08 00:43:15" & there is no development module posted for the moment, so this patch is not immediately applicable for many people (supposing that it works).

People using pgsql apparently went through a similar process over the same mismatch, which also led to patches:
http://drupal.org/node/357654
http://drupal.org/node/386966

At any rate, I am getting similar mismatches for the following modules on Drupal 6.10:
The most persistent has been blog.api:

blogapi_files.fid is part of the primary key but is not specified to be 'not null'.
blogapi_files
column fid:

declared: array('type' => 'serial')

actual: array('type' => 'serial', 'not null' => TRUE, 'disp-width' => '11')

I say most persistent because I am testing various site environments (different sets of modules) and have several sites running on localhost.
Blog.api threw its first mismatch for me in 6.9. It did not on my first installation of 6.10 (which continues to be free of this), but did on all subsequent ones. The only differences between these 6.10 systems is the choice of modules installed and the order in which they were enabled. Could the combination of certain modules, their number, how many get enabled with one "save" , etc, have any affect on schema's ability to deal with the input? Put another way, why do I have one installation without mismatching (a rhetorical question).

To take this one step further, since the update of advanced forum and author pane (march 23), I have included those updates in two clean installs. For both environments, the choice of modules is the same (except one runs Domain access). In both cases Schema tells me:

activity.aid is part of the primary key but is not specified to be 'not null'.

activity
◦ column aid:
declared: array('type' => 'serial')
actual: array('type' => 'serial', 'not null' => TRUE, 'disp-width' => '11')
◦ activity_history.uid, aid is part of the primary key but is not specified to be 'not null'.

&

activity_history
◦ primary key:
declared: array('uid, aid')
actual: array('uid', 'aid')

as well as the ever-present blog.api report, in these two last installs as above.

Judging the significance of these reports by schema is beyond me at this point. So, if the information I am offering here is redundant or of no use, my apologies.
After all, it occurs to me that one easy solution for the problems here would be to uninstall Schema for my production site until such time as I really need and have better understood the arrays it is offering.

Thank you for your time

I just ran into this with pgsql tables with negative default values. (eg: system.schema_version)

Dunno about the rest of the MySQL complaints here, but I made a quick fix for the problem I saw:

engines/schema_pgsql.inc
94a95,99
> // pgsql displays negative default numbers like (-1), (-1.0)
> // strip the leading '(' so we don't parse it as 0.
> if (strpos($col['default'], '(-' ) === 0){
> $col['default'] = substr($col['default'], 1);
> }

edit: nm, This is probably better:
http://drupal.org/node/357654

Is there any reproducible issue remaining with the current CVS (I committed a fix to the disp-width mixmatches today)? I can't reproduce any current problem with bogus mismatches...

Thanks.