Bug #27098 Cluster: tablespace names are case sensitive

Description:
Tablespace identifiers should be case insensitive
because that is what will happen with
Falcon tablespaces (according to an email sent to dev-architecture
by Jim Starkey in thread "Table Space Names"), and because that
is what MySQL generally does for identifiers of objects other than
databases or tables. See The MySQL Reference Manual,
9.2.2. Identifier Case Sensitivity
http://dev.mysql.com/doc/refman/5.1/en/identifier-case-sensitivity.html
(Triggers are an exception but that's a verified bug, Bug#15187.)

But currently I can create a tablespace named 'george'
and a tablespaced named 'GEORGE'.

How to repeat:
mysql> create logfile group l add undofile '/usr/local/mysql/var/undo_file' initial_size = 100000 engine=ndbcluster;
Query OK, 0 rows affected (1.61 sec)

mysql> create tablespace george add datafile '/usr/local/mysql/var/file' use logfile group l initial_size = 1000000 engine=ndbcluster;
Query OK, 0 rows affected (1.65 sec)

mysql> create tablespace GEORGE add datafile '/usr/local/mysql/var/GEORGE' use logfile group l initial_size = 1000000 engine=ndbcluster;
Query OK, 0 rows affected (1.68 sec)

See also
Bug #35257  	Falcon: tablespace names are case sensitive

Rules for tablespace names follow established MySQL conventions for database object names. The documentation should reflect this.

Changed category to Docs; reassigned to myself for rectification; changed Synopsis to reflect true nature of issue.

Thank you for your bug report. This issue has been addressed in the documentation. The updated documentation will appear on our website shortly, and will be included in the next release of the relevant products.

I believe that the title (yes, I call it a title)
should generally be left alone. Changing what
other people wrote is a step more than commenting.

As for disposition of the bug -- this may be the
"intended behaviour" for cluster, but the storage
engine maker should not make the rules for case
sensitivity, that's a server decision. Of course,
if it can be shown that this behaviour follows the
"MySQL conventions for database object names",
then it's not a bug. But my description of the
convention -- see the original bug report -- should
be accepted unless there is contrary evidence.