MySQL Bugs: #29665: init_connect in config file prevents client SET NAMES

Bug #29665	init_connect in config file prevents client SET NAMES
Submitted:	9 Jul 2007 22:13	Modified:	11 Jul 2007 11:25
Reporter:	Peter Laursen (Basic Quality Contributor)	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server	Severity:	S2 (Serious)
Version:	5.0.37 ... probably any	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	qc

Description:
I have and issue with init_connect configuration parameter!

http://dev.mysql.com/doc/refman/5.0/en/mysqld-option-tables.html

explains: For status variables, the scope of the variable is shown (Scope) as either global, session, or both.

init_connect is described a GLOBAL status variable!
Still it is not clear if a client may override this.

The particular issue is that we have a customer having 

"init_connect='SET NAMES cp1251'"

in his configuration file.  This prevents our application to "SET NAMES UTF8" succesfully.  The server maps the individual bytes of 2-byte cyrillic characters to cp1251 charset.

Is this expected behaviour?  I think http://dev.mysql.com/doc/refman/5.0/en/charset.html tells that a client may SET NAMES for the connection and client independently of the GLOBAL setting?

you can read the discussion in our Forums:
http://www.webyog.com/forums//index.php?showtopic=3356

How to repeat:
see above.

Suggested fix:
allow a CLIENT to SET NAMES!

Thank you for the report.

I can not repeat described behaviour using dollowing test loadable by MySQL test suite:

create user mysqltest1@localhost;
grant all privileges on test.* to mysqltest1@localhost;

connect (con1,localhost,mysqltest1,,);
connection con1;

show variables like '%char%';

set names 'utf8';

show variables like '%char%';

bug29665-master.opt contains:

--set-variable=init_connect="SET NAMES 'cp1251'"

Result:

=====mysql-5.0-community=====
=====bug29665=====
create user mysqltest1@localhost;
grant all privileges on test.* to mysqltest1@localhost;
show variables like '%char%';
Variable_name   Value
character_set_client    cp1251
character_set_connection        cp1251
character_set_database  latin1
character_set_filesystem        binary
character_set_results   cp1251
character_set_server    latin1
character_set_system    utf8
character_sets_dir      /users/ssmirnova/src/mysql-5.0-community/sql/share/charsets/
set names 'utf8';
show variables like '%char%';
Variable_name   Value
character_set_client    utf8
character_set_connection        utf8
character_set_database  latin1
character_set_filesystem        binary
character_set_results   utf8
character_set_server    latin1
character_set_system    utf8
character_sets_dir      /users/ssmirnova/src/mysql-5.0-community/sql/share/charsets/

If you think my test is not correct, fell free to fix it and reopen the report.

Ok .. I would like to ask you to try this (I am somewhat disabled as I cannot operate cyrillic locale and keyboard)

1) start server with the init_connect command in configuration.

2) create a small table with just a few string columns.  Use default charset cp1251 for the table (I do not think that matters actually, but the customer uses cp1251 a default charset everywhere (server, databases, tables).

3) set names utf8

4) insert into the_table values ({some cyrillic strings})

5) select * from the_table.  Does it display the strings that were inserted?

You must of course use a client supporting utf8.  I do not think 'mysql' client on Windows does!

Thank you for the feedback.

I still get correct results:

create user mysqltest1@localhost;
grant all privileges on test.* to mysqltest1@localhost;

connect (con1,localhost,mysqltest1,,);
connection con1;

create table t1(f1 varchar(255)) DEFAULT CHARSET=cp1251;

#it contains query insert into t1 values('тест'); in CP1251
source $HOME/bug29665.sql;

show variables like '%char%';

set names 'utf8';

show variables like '%char%';

insert into t1 values('другой');

select * from t1;

Result:

<skip>
select * from t1;
f1
тест
другой