I've found what I believe to be a problem with the example storage engine.
The problem also exists in the InnoDB and CSV storage engines. Strictly
speaking, I can't call it a bug, since I don't think that any adverse
behavior is generated for these cases. However, it does adversely affect
our storage engine, which long ago used the example storage engine as its
inspiration. Consequently, I would suggest that the example storage engine
be fixed to prevent future storage engines from making a similar mistake.
The problem is this: in the storage engine initialization function
(example_init_func), the example_open_tables hash table is initialized to
use the system_charset_info character set. This hash table is used to
track information on a table-wide basis that is shared among handlers
belonging to that table. However, because system_charset_info uses the
utf8_general_ci collation, table names that differ only in letter case
(e.g. ABC and abc) will hash to the same share. When our storage engine
has two such tables open at the same time, odd behavior occurs because of
this collision. I suspect that the appropriate solution is to use
my_charset_bin instead of system_charset_info, as the federated engine
does.
Thank you,
Tim Clark
