(case MY_LEX_USER_VARIABLE_DELIMITER for multichar strings)
and my_mbcharlen


include/m_ctype.h:
  a trivial optimization of my_mbcharlen (case !USE_MB)
sql/sql_lex.cc:
  a little optimization in yylex 
  (case MY_LEX_USER_VARIABLE_DELIMITER for multichar strings)

into bar.intranet.mysql.r18.ru:/usr/home/bar/mysql-4.1

sql-common/client.c:
  'virtual' method initialization

into deer.(none):/home/hf/work/mysql-4.1.2211

previous one had error


libmysqld/lib_sql.cc:
  memdup_mysql deleted
sql/sql_class.h:
  String instead of char*
sql/sql_parse.cc:
  storing of the rest of the query

include/mysql.h:
  Auto merged
libmysql/libmysql.c:
  Auto merged
tests/client_test.c:
  manual merge

mysql-test/r/mysqldump.result:
  fixed mistake after merge

into eagle.mysql.r18.ru:/home/vva/work/BUG_2593/mysql-4.1


sql/sql_lex.cc:
  Auto merged

into eagle.mysql.r18.ru:/home/vva/work/BUG_2593/mysql-4.1


sql/mysql_priv.h:
  Auto merged
sql/sql_lex.cc:
  Auto merged
sql/sql_show.cc:
  Auto merged

sql/sql_show.cc:
  some optimization in append_identifier

into deer.(none):/home/hf/work/mysql-4.1.1438

libmysqld/lib_sql.cc:
  mysql.info set to the right value

"MySQL server does not detect if garbage chara at the end of query"

Allow the parser to see the garbage characters.
Garbage should cause the parser to report an error.


sql/sql_lex.cc:
  Return END_OF_INPUT when at the end of the input buffer.
  Allows the parser to determine if there is junk after a \0 character.
sql/sql_parse.cc:
  Undo 1.314.1.1 04/02/11 12:32:42 guilhem@mysql.com
sql/sql_prepare.cc:
  Undo 1.73 04/02/11 12:32:42 guilhem@mysql.com

into mysql.com:/home/dlenev/src/mysql-4.1-bg2248


include/mysql.h:
  Auto merged
libmysql/libmysql.c:
  Auto merged

into bar.intranet.mysql.r18.ru:/usr/home/bar/mysql-4.1

CONVERT3 was removed, it was for test purposes,
and rather harmful.

into deer.(none):/home/hf/work/mysql-4.1.2208


sql/sql_parse.cc:
  Auto merged

Made code shorter and more correct


libmysql/client_settings.h:
  cli_next_result removed
libmysql/libmysql.c:
  cli_next_result removed

into mysql.com:/home/mysql_src/mysql-4.1

"MySQL server does not detect if garbage chars at the end of query":

Detect garbage chars at the end of the query or at the end of a query
for a prepared statement (which happens if mysql_real_query() or mysql_prepare()
were called with a too big 'length' parameter (bigger than the real intended
length of the query: then we receive a query + garbage characters from the
client). This resulted in garbage chars written into the binlog.
Now instead the client receives something like:
'You have an error in your SQL syntax.  Check the manual that corresponds
to your MySQL server version for the right syntax to use near '!stmt'
at line 1' i.e. the server is pointing at the weird tail of the query
(this '!stmt' are the garbage chars sent by the client).
All tests pass, except mysqldump.test and ctype_utf8.test but they failed
before the patch.


sql/sql_parse.cc:
  Detect garbage chars at the end of the query
  (which happens if mysql_real_query() was called with a too big 'length'
  parameter (bigger than the real intended length of the query: then
  we receive a query + garbage characters from the client).
sql/sql_prepare.cc:
  Detect garbage chars at the end of the query
  (which happens if mysql_prepare() was called with a too big 'length'
  parameter (bigger than the real intended length of the query: then
  we receive a query + garbage characters from the client).
tests/client_test.c:
  The change to sql_parse.cc and sql_prepare.cc rightfully gives many
  syntax errors to tests/client_test.c which is full of
  mysql_prepare(mysql, "SHOW TABLES", 100).
  Correcting all these commands.

  No needs to load charset index if the character set is build-in.


client/mysql.cc:
  No needs to load charset index if the character set is build-in.
client/mysqlcheck.c:
  No needs to load charset index if the character set is build-in.
client/mysqldump.c:
  No needs to load charset index if the character set is build-in.
client/mysqlimport.c:
  No needs to load charset index if the character set is build-in.

into mysql.com:/home/dlenev/src/mysql-4.1-bg2248

into deer.(none):/home/hf/work/mysql-4.1.2208

into mysql.com:/home/mysql_src/mysql-4.1

added setting of 'neg' in Item_param::set_time() (looks like the only forgotten
member).
It's the second place I find where 'neg' was forgotten.
The symptom was unexpected negative times in the binary log when running
tests/client_test.c (test_date() in fact):
# at 43009
#040210 15:46:42 server id 1  log_pos 43009     Query   thread_id=1     exec_time=0     error_code=0
SET TIMESTAMP=1076424402;
INSERT INTO test_date VALUES('2000-01-10 11:16:20','-11:16:20' etc


sql/item.cc:
  Don't forget to copy 'neg'.

into eagle.mysql.r18.ru:/home/vva/work/BUG_2592/mysql-4.1

in sql/sql_lex.cc


sql/sql_lex.cc:
  code cleanup of processing MY_LEX_USER_VARIABLE_DELIMITER

into mysql.com:/home/mysql_src/mysql-4.1

into mysql.com:/home/dlenev/src/mysql-4.1-bg2248

  FreeBSD "ps" detection usually failed, in 90% cases,
  on FreeBSD-5.1. This change should work fine under
  5.x and 4.x, and I believe in 3.x. too. 


configure.in:
  FreeBSD "ps" detection usually failed, in 90% cases. Thi

into deer.(none):/home/hf/work/mysql-4.1.2208


sql/sql_class.h:
  Auto merged
sql/sql_parse.cc:
  Auto merged

It was together with the previous but. This test tends to prove it.

into bar.intranet.mysql.r18.ru:/usr/home/bar/mysql-4.1

into eagle.mysql.r18.ru:/home/vva/work/BUG_2592/mysql-4.1


sql/sql_lex.cc:
  Auto merged

mysql-test/r/mysqldump.result:
  correcting result after merge

client/mysqldump.c:
  Auto merged
mysql-test/r/mysqldump.result:
  e

mysql-test/t/mysqldump.test:
  added skiped newline to the end of file