Bug #34706 FALCON_TABLES shows wrong information on temporary tables

Description:
There is an issue with reporting temporary tables with FALCON_TABLES.

How to repeat:
mysql> create temporary table test.t1 (f1 integer) engine=falcon;
Query OK, 0 rows affected (0.02 sec)
mysql> select * from information_schema.FALCON_TABLES;
+-------------+------------+-----------+------------------+---------------+
| SCHEMA_NAME | TABLE_NAME | PARTITION | TABLESPACE       | INTERNAL_NAME |
+-------------+------------+-----------+------------------+---------------+
| TMP         |            |           | FALCON_TEMPORARY | #SQL7D29_1_2  |
+-------------+------------+-----------+------------------+---------------+
1 row in set (0.00 sec)

In my humble opinion, SCHEMA_NAME should be "test", TABLE_NAME must be "t1" and, in case

Thank you for the report.

Verified as described.

possibly related to 34705

This works on Windows (but still not on Linux):

+-------------+------------+-----------+------------------+--------------+
| SCHEMA_NAME | TABLE_NAME | PARTITION | TABLESPACE       | INTERNAL_NAME|
+-------------+------------+-----------+------------------+--------------+
| TMP         |            |           | FALCON_TEMPORARY | #SQLF5C_2_0  |
| TEST        | T1         |           | FALCON_USER      | T1           |
+-------------+------------+-----------+------------------+--------------+

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.

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.