- 13 Feb, 2004 5 commits
-
-
bar@bar.intranet.mysql.r18.ru authored
into bar.intranet.mysql.r18.ru:/usr/home/bar/mysql-4.1
-
hf@deer.(none) authored
-
bar@bar.intranet.mysql.r18.ru authored
-
hf@deer.(none) authored
into deer.(none):/home/hf/work/mysql-4.1.2211
-
hf@deer.(none) authored
previous one had error
-
- 12 Feb, 2004 8 commits
-
-
konstantin@mysql.com authored
-
vva@eagle.mysql.r18.ru authored
-
vva@eagle.mysql.r18.ru authored
into eagle.mysql.r18.ru:/home/vva/work/BUG_2593/mysql-4.1
-
vva@eagle.mysql.r18.ru authored
into eagle.mysql.r18.ru:/home/vva/work/BUG_2593/mysql-4.1
-
vva@eagle.mysql.r18.ru authored
-
hf@deer.(none) authored
into deer.(none):/home/hf/work/mysql-4.1.1438
-
hf@deer.(none) authored
-
acurtis@pcgem.rdg.cyberkinetica.com authored
"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.
-
- 11 Feb, 2004 11 commits
-
-
dlenev@mysql.com authored
into mysql.com:/home/dlenev/src/mysql-4.1-bg2248
-
bar@bar.intranet.mysql.r18.ru authored
into bar.intranet.mysql.r18.ru:/usr/home/bar/mysql-4.1
-
bar@bar.intranet.mysql.r18.ru authored
CONVERT3 was removed, it was for test purposes, and rather harmful.
-
hf@deer.(none) authored
into deer.(none):/home/hf/work/mysql-4.1.2208
-
hf@deer.(none) authored
Made code shorter and more correct
-
dlenev@mysql.com authored
-
guilhem@mysql.com authored
into mysql.com:/home/mysql_src/mysql-4.1
-
guilhem@gbichot2.local authored
"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.
-
bar@bar.intranet.mysql.r18.ru authored
No needs to load charset index if the character set is build-in.
-
dlenev@mysql.com authored
into mysql.com:/home/dlenev/src/mysql-4.1-bg2248
-
hf@deer.(none) authored
into deer.(none):/home/hf/work/mysql-4.1.2208
-
- 10 Feb, 2004 16 commits
-
-
guilhem@mysql.com authored
into mysql.com:/home/mysql_src/mysql-4.1
-
guilhem@gbichot2.local authored
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
-
vva@eagle.mysql.r18.ru authored
into eagle.mysql.r18.ru:/home/vva/work/BUG_2592/mysql-4.1
-
vva@eagle.mysql.r18.ru authored
in sql/sql_lex.cc
-
guilhem@mysql.com authored
into mysql.com:/home/mysql_src/mysql-4.1
-
dlenev@mysql.com authored
into mysql.com:/home/dlenev/src/mysql-4.1-bg2248
-
konstantin@mysql.com authored
-
bar@bar.intranet.mysql.r18.ru authored
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.
-
hf@deer.(none) authored
into deer.(none):/home/hf/work/mysql-4.1.2208
-
bar@bar.intranet.mysql.r18.ru authored
It was together with the previous but. This test tends to prove it.
-
bar@bar.intranet.mysql.r18.ru authored
into bar.intranet.mysql.r18.ru:/usr/home/bar/mysql-4.1
-
vva@eagle.mysql.r18.ru authored
into eagle.mysql.r18.ru:/home/vva/work/BUG_2592/mysql-4.1
-
vva@eagle.mysql.r18.ru authored
-
vva@eagle.mysql.r18.ru authored
-
vva@eagle.mysql.r18.ru authored
-
guilhem@gbichot2.local authored
Don't show PSEUDO_THREAD_ID in SHOW VARIABLES because: - we don't want people to discover this variable as it could never do good to set it (it was designed for use by mysqlbinlog only, so that a thread can have several temp tables of the same name at the same time) - if we show it in SHOW VARIABLES, Mysql Administrator will display it and this will force us to put a description, so all MySQL Administrator user will be aware of this variable, some may have the idea to set it with a SET command, and then it will cause bad things. The variable is still settable, and still visible with SELECT @@.
-