List:Internals« Previous MessageNext Message »
From:Alexander Barkov Date:December 23 2009 3:12pm
Subject:Re: system_charset_info
View as plain text  
Hi Yan,

Yan Yu wrote:
> HI, Monty, 
> thanks a LOT for all the information and tips!
> 
> Yan> the results from "describe [table name] would miss information on two
> columns: Type and Null Column.
> Yan> e.g., result for "describe Columns;" returns the following:
> Yan> +--------------------------+------+------+-----+---------+-------+
> Yan> | Field                    | Type | Null | Key | Default | Extra |
> Yan> +--------------------------+------+------+-----+---------+-------+
> Yan> | TABLE_CATALOG            |      |      |     | NULL    |       |
> Yan> | TABLE_SCHEMA             |      |      |     |         |       |
> Yan> | TABLE_NAME               |      |      |     |         |       |
> Yan> | COLUMN_NAME              |      |      |     |         |       |
> Yan> | ORDINAL_POSITION         |      |      |     | 0       |       |
> Yan> | COLUMN_DEFAULT           |      |      |     | NULL    |       |
> 
> Yan> I have not been able to pinpoint the root cause yet, BUT after I change
> Yan> one line of ST_FIELD_INFO columns_fields_info[] from
> 
> Yan> +  {"COLUMN_TYPE", 65535, MYSQL_TYPE_STRING, 0, 0, "Type", OPEN_FRM_ONLY},
> Yan> to
> Yan> -  {"COLUMN_TYPE", 5000, MYSQL_TYPE_STRING, 0, 0, "Type", OPEN_FRM_ONLY},
> 
> Yan> the problem seems gone.
> 
> Yan> My Q is:  would it be safe for me to make this change?
> 
> For your purpose, the above should be safe.
> 
> However, I need to look at what could cause the above display bug.
> ------------------------
> Please do keep me posted on this one if you find anything.  BTW, the above hack fixed
> the display problem for the table created in the create.test. However 
> those two columns are still missing with the command "describe columns".  It escaped
> me that 
>  
> 
> 
> Yan> (3) problems caused by conversion between different charsets. mb_wc() or
> wc_mb()
> Yan> our system_charset uses latin1, and
> Yan> "create.test"  includes the following SQL statement:
> Yan> set names utf8;
> Yan> create database
> имя_базы_в_кодировке_утф8_длиной_больше_чем_45;
> Yan> use
> имя_базы_в_кодировке_утф8_длиной_больше_чем_45;
> Yan> select database();
> 
> Yan>
> "имя_базы_в_кодировке_утф8_длиной_больше_чем_45" was
> converted to unicode string internally.
> Yan> it seems like either the conversion is mis-handled somewhere, or the
> conversion is missing in one direction. Would this be possible?
> 
> This could be becase of two reasons
> 
> - files_charset_info needs to be utf8.
> or
> - files_charset_info needs to be same as system_charset_info.

The same to system_charset_info.

Please also have a look into my previous letter.

> 
> Bar, can you answer this one ?
> 
> Yan> somehow, the database name is represented internally as
> Yan> "???_????_?_?????????_???8_??????_??????_???_45",
> Yan> and this same string  is also returned back to the client for "select
> database();" command.
> Yan> I do not know much about the unicode string, so not sure about the conversion
> code.
> 
> Regards,
> Monty

Thread
system_charset_infoYan Yu20 Dec
  • re: system_charset_infoMichael Widenius22 Dec
  • Re: system_charset_infoAlexander Barkov23 Dec
Re: system_charset_infoMichael Widenius22 Dec
  • RE: system_charset_infoYan Yu23 Dec
  • Re: system_charset_infoAlexander Barkov23 Dec
    • Re: system_charset_infoYan Yu24 Dec