MySQL Bugs: #34705: FALCON_TABLES shows wrong TABLE

Bug #34705	FALCON_TABLES shows wrong TABLE_NAME
Submitted:	20 Feb 2008 21:14	Modified:	18 Oct 2008 15:58
Reporter:	Hakan Küçükyılmaz	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Falcon storage engine	Severity:	S3 (Non-critical)
Version:	6.0.4, 6.0.5	OS:	Any
Assigned to:	Sergey Vojtovich	CPU Architecture:	Any

Description:
It appears that if TABLE_NAME contains characters outside of ASCII, you can not use the "escaped" TABLE_NAME to drop the table.

How to repeat:
For example:

mysql> create table `###` (f1 integer not null) engine=falcon;
Query OK, 0 rows affected (0.01 sec)

mysql> select * FROM information_schema.FALCON_TABLES;
+-------------+-----------------+-----------+------------------+-----------------+
| SCHEMA_NAME | TABLE_NAME      | PARTITION | TABLESPACE       | INTERNAL_NAME   |
+-------------+-----------------+-----------+------------------+-----------------+
| TEST        | T3              |           | FALCON_TEMPORARY | T3              |
| TEST        | T12             |           | FALCON_TEMPORARY | T12             |
| TEST        | @0023@0023@0023 |           | FALCON_USER      | @0023@0023@0023 |
+-------------+-----------------+-----------+------------------+-----------------+

mysql> drop table `@0023@0023@0023`;
ERROR 1051 (42S02): Unknown table '@0023@0023@0023'

This means that one can not safely iterate over all rows of FALCON_TABLES and perform
operations on individual tables. Unless one manually converts @0023@0023@0023 into a ###,
there is no way to match that table to , say, information_schema.TABLES, because the
@0023@0023@0023 does not appear there, just the ###.

Thank you for the report.

Verified as described.

Kevin,
I'm not sure that something has to be done to it.Falcon never sees ### , server passes only the encoded string to it (@0023@0023@0023), in fact together with path. encoding/decoding is not made a public (plugin accessible) API. 

I believe the problem the difference in perception of "table" between plugin API and Falcon- server is talking in filesystem path terms, Falcon needs table names and tablespaces. Thus for the time being, I'd classify that as 'Won't fix' - if server would pass the schema and table names directly, the problem would not ever exist.

The problem described by Hakan (inability to use table names from falcon_tables)
BTW is simply solved - use standard information_schema.tables for any purposes.

In exotic cases, like manual error analysis and debugging, well then one could live with @0023 as well.

Well, after some debugging around found that a some info is passed in little
documented HA_CREATE_INFO structure and it has a member named 'alias'
that looks like undecorated table name.

Assigning to Sergey Votjovich.  We have decided to delete INFORMATION_SCHEME.FALCON_TABLES which should eliminate this problem.

>>Vlad wrote;
>>
>> How would you fix these bugs? For example, to have proper table name as
>> defined by user (in all cases, that is even with non-latin characters and
>> after RENAME) we would need  filename_to_tablename() , that is banned from
>> server API.  And possibly we'd also need to fix Falcon uppercasing while
>> we are at it ;) Too much hacking, is not it?

>Ann wrote;
>Too much hacking and too little value, I agree.  Also too much confusion
>about what table to trust, giving that there is a very large overlap
>between TABLES and FALCON_TABLES.  I can think of no case where the
>internal Falcon name is of interest to anything but Falcon.  So, fine,
>lets get rid of FALCON_TABLES and close all three bugs.

See http://lists.mysql.com/commits/50640

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/50640

2761 Sergey Vojtovich	2008-07-29
      BUG#29211 - Falcon: information_schema has a falcon_tables view
      BUG#34705 - FALCON_TABLES shows wrong TABLE_NAME
      BUG#34706 - FALCON_TABLES shows wrong information on temporary tables
      
      There were several problems relating to INFORMATION_SCHEMA.FALCON_TABLES,
      e.g.:
      - there is no worklog entry for I_S.FALCON_TABLES, so it is not
        there by design
      - MySQL already has I_S.FILES and I_S.TABLES, which provide
        duplicating information
      - it didn't show properly table names with non-ascii characters
      - it didn't show properly table and schema names for temporary
        tables
      
      This patch removes INFORMATION_SCHEMA.FALCON_TABLES and all
      relevant code.
      
      No test case needed for this fix - it is already covered by existing
      tests.

Was pushed to 6.0.7.

Pushed into 6.0.7-alpha  (revid:svoj@mysql.com-20080729104539-5grheqzat2gs0avq) (version source revid:v.narayanan@sun.com-20080820070709-nx09bk6qx81osd5s) (pib:3)

Documented in the 6.0.7 changelog as follows:

        *IMPORTANT CHANGE* The INFORMATION_SCHEMA.FALCON_TABLES table has been 
        removed.

Updated se-falcon-stats section of 6.0 Manual accordingly.