An error occurred fetching the project authors.
- 13 Nov, 2006 1 commit
-
-
holyfoot/hf@mysql.com/deer.(none) authored
-
- 12 Sep, 2006 1 commit
-
-
timour/timka@lamia.home authored
The cause of the bug was an incomplete fix for bug 18080. The problem was that setup_tables() unconditionally reset the name resolution context to its 'tables' argument, which pointed to the first table of an SQL statement. The bug fix limits resetting of the name resolution context in setup_tables() only in the cases when the context was not set by earlier parser/optimizer phases.
-
- 02 Aug, 2006 1 commit
-
-
svoj@may.pils.ru authored
columns Fixed confusing warning. Quoting INSERT section of the manual: ---- Inserting NULL into a column that has been declared NOT NULL. For multiple-row INSERT statements or INSERT INTO ... SELECT statements, the column is set to the implicit default value for the column data type. This is 0 for numeric types, the empty string ('') for string types, and the "zero" value for date and time types. INSERT INTO ... SELECT statements are handled the same way as multiple-row inserts because the server does not examine the result set from the SELECT to see whether it returns a single row. (For a single-row INSERT, no warning occurs when NULL is inserted into a NOT NULL column. Instead, the statement fails with an error.) ---- This is also true for LOAD DATA INFILE. For INSERT user can specify DEFAULT keyword as a value to set column default. There is no similiar feature available for LOAD DATA INFILE.
-
- 19 Jul, 2006 1 commit
-
-
REPLACE ... SELECT would require INSERT privileges on certain tables when SELECT really suffices. Require INSERT only on target table.
-
- 19 Jun, 2006 2 commits
-
-
gkodinov@mysql.com authored
There was an incomplete reset of the name resolution context, that caused INSERT ... SELECT ... JOIN statements to resolve not by joint row type calculated for the join. Removed the redundant re-initialization of the context, because mysql_insert_select_prepare() now correctly saves/restores the context.
-
gkodinov@mysql.com authored
tables Currently in INSERT ... SELECT ... LIMIT ... the compiler uses a temporary table to store the results of SELECT ... LIMIT .. and then uses that table as a source for INSERT. The problem is that in some cases it actually skips the LIMIT clause in doing that and materializes the whole SELECT result set regardless of the LIMIT. This fix is limiting the process of filling up the temp table with only that much rows that will be actually used by propagating the LIMIT value.
-
- 23 Jan, 2006 1 commit
-
-
ingo@mysql.com authored
Change "duplicate key" message to print key name instead of key number.
-
- 01 Dec, 2005 1 commit
-
-
gluh@eagle.intranet.mysql.r18.ru authored
SQL mode TRADITIONAL Message is chenged from 'ER_WARN_NULL_TO_NOTNULL' to 'ER_BAD_NULL_ERROR'
-
- 27 Oct, 2005 1 commit
-
-
jani@ua141d10.elisa.omakaista.fi authored
-
- 25 Oct, 2005 1 commit
-
-
evgen@moonbone.local authored
VALUES() can only refer to table insert going to. But Item_insert_value::fix_fields() were passing to it's arg full table list, This results in finding second column which shouldn't be found, and failing with error about ambiguous field. Item_insert_value::fix_fields() now passes only first table of full table list.
-
- 15 Sep, 2005 1 commit
-
-
serg@serg.mylan authored
-
- 09 Sep, 2005 1 commit
-
-
evgen@moonbone.local authored
Customer's test case for bug#12695 Item_func_isnull::update_used_tables() did not update const_item_cache.
-
- 12 Aug, 2005 1 commit
-
-
timour@mysql.com authored
"Process NATURAL and USING joins according to SQL:2003". * Some of the main problems fixed by the patch: - in "select *" queries the * expanded correctly according to ANSI for arbitrary natural/using joins - natural/using joins are correctly transformed into JOIN ... ON for any number/nesting of the joins. - column references are correctly resolved against natural joins of any nesting and combined with arbitrary other joins. * This patch also contains a fix for name resolution of items inside the ON condition of JOIN ... ON - in this case items must be resolved only against the JOIN operands. To support such 'local' name resolution, the patch introduces a stack of name resolution contexts used at parse time. NOTICE: - This patch is not complete in the sense that - there are 2 test cases that still do not pass - one in join.test, one in select.test. Both are marked with a comment "TODO: WL#2486". - it does not include a new test specific for the task
-
- 27 Jun, 2005 1 commit
-
-
monty@mishka.local authored
#9728 'Decreased functionality in "on duplicate key update #8147 'a column proclaimed ambigous in INSERT ... SELECT .. ON DUPLICATE' This ensures fields are uniquely qualified and also that one can't update other tables in the ON DUPLICATE KEY UPDATE part
-
- 22 Jun, 2005 1 commit
-
-
evgen@moonbone.local authored
Remove changes made by bug fix #8147. They strips list of insert_table_list to only insert table, which results in error reported in bug #9728. Added flag to Item to resolve ambigous fields reported in bug #8147.
-
- 21 Jun, 2005 1 commit
-
-
evgen@moonbone.local authored
Temporary field wasn't restored to default values after ON DUPLICATE KEY UPDATE event, which results in wrong data being inserted in new record.
-
- 31 Mar, 2005 1 commit
-
-
jimw@mysql.com authored
up a couple of tests and adjusting the output of others. Exposes two bugs (9472 and 9508).
-
- 16 Mar, 2005 1 commit
-
-
dlenev@brandersnatch.localdomain authored
Now one can use user variables as target for data loaded from file (besides table's columns). Also LOAD DATA got new SET-clause in which one can specify values for table columns as expressions. For example the following is possible: LOAD DATA INFILE 'words.dat' INTO TABLE t1 (a, @b) SET c = @b + 1; This patch also implements new way of replicating LOAD DATA. Now we do it similarly to other queries. We store LOAD DATA query in new Execute_load_query event (which is last in the sequence of events representing LOAD DATA). When we are executing this event we simply rewrite part of query which holds name of file (we use name of temporary file) and then execute it as usual query. In the beggining of this sequence we use Begin_load_query event which is almost identical to Append_file event
-
- 16 Feb, 2005 1 commit
-
-
serg@serg.mylan authored
-
- 03 Feb, 2005 1 commit
-
-
guilhem@mysql.com authored
we store 7 bytes (1 + 2*3) in every Query_log_event. In the future if users want binlog optimized for small size and less safe, we could add --binlog-no-charset (and binlog-no-sql-mode etc): charset info is something by design optional (even if for now we don't offer possibility to disable it): it's not a binlog format change. We try to reduce the number of get_charset() calls in the slave SQL thread to a minimum by caching the charset read from the previous event (which will often be equal to the one of the current event). We don't use SET ONE_SHOT for charset-aware repl (we still do for timezones, will be fixed later). No more errors if one changes the global value of charset vars on master or slave (as we log charset info in all Query_log_event). Not fixing Load_log_event as it will be rewritten soon by Dmitri. Testing how mysqlbinlog behaves in rpl_charset.test. mysqlbinlog needs to know where charset file is (to be able to convert a charset number found in binlog (e.g. in User_var_log_event) to a charset name); mysql-test-run needs to pass the correct value for this option to mysqlbinlog. Many result udpates (adding charset info into every event shifts log_pos in SHOW BINLOG EVENTS). Roughly the same job is to be done for timezones :)
-
- 19 Jan, 2005 3 commits
-
-
ingo@mysql.com authored
Version for 5.0. Committed for merge. If the result table is one of the select tables in INSERT SELECT, we must not disable the result tables indexes before selecting. Now the preparation is split into two prepare methods. The first detects the situation and defers some preparations until the second phase.
-
ingo@mysql.com authored
Version for 4.1. Committed for merge. If the result table is one of the select tables in INSERT SELECT, we must not disable the result tables indexes before selecting. mysql_execute_command() detects the match for other reasons and adds the flag OPTION_BUFFER_RESULT to the 'select_options'. In this case the result is put into a temporary table first. Hence, we can defer the preparation of the insert table until the result is to be used.
-
ingo@mysql.com authored
Version for 4.0. Committed for merge. If the result table is one of the select tables in INSERT SELECT, we must not disable the result tables indexes before selecting. mysql_execute_command() detects the match for other reasons and adds the flag OPTION_BUFFER_RESULT to the 'select_options'. In this case the result is put into a temporary table first. Hence, we can defer the preparation of the insert table until the result is to be used.
-
- 16 Jan, 2005 1 commit
-
-
serg@serg.mylan authored
-
- 06 Dec, 2004 1 commit
-
-
monty@mysql.com authored
Fixed compiler warnings Fix core dump when sending SIGHUP to mysqld
-
- 03 Dec, 2004 1 commit
-
-
jimw@mysql.com authored
-
- 02 Dec, 2004 1 commit
-
-
jimw@mysql.com authored
insertion of new records partially failed. It would get logged because of the logic to log a partially-failed 'INSERT ... SELECT' (which can't be rolled back in non-transactional tables), but 'CREATE TABLE ... SELECT' is always rolled back on failure, even for non-transactional tables. (Bug #6682) (Original fix reimplemented after review by Serg and Guilhem.)
-
- 02 Oct, 2004 1 commit
-
-
monty@mishka.local authored
More tests. Better error messages. Fixed bug when checking if we updated all needed columns for INSERT. Give an error if we encounter a wrong float value during parsing. Don't print DEFAULT for columns without a default value in SHOW CREATE/SHOW FIELDS. Fixed UPDATE IGNORE when using STRICT mode.
-
- 16 Jun, 2004 1 commit
-
-
paul@ice.snake.net authored
and affected test results.
-
- 16 Feb, 2004 1 commit
-
-
monty@mysql.com authored
Added more DBUG statements Ensure that we are comparing end space with BINARY strings Use 'any_db' instead of '' to mean any database. (For HANDLER command) Only strip ' ' when comparing CHAR, not other space-like characters (like \t)
-
- 06 Feb, 2004 1 commit
-
-
konstantin@mysql.com authored
-
- 19 Dec, 2003 1 commit
-
-
guilhem@gbichot2 authored
For previous commit I had run only rpl* tests, here the other ones had a few surprises. Latest status: - all tests pass - all replication tests pass with Valgrind This is the final-final commit & push. Doc remains.
-
- 16 Dec, 2003 1 commit
-
-
vva@eagle.mysql.r18.ru authored
(fixed #bug 2012)
-
- 10 Dec, 2003 1 commit
-
-
Deprecate the use of TYPE=... Preferred syntax is ENGINE=
-
- 08 Oct, 2003 1 commit
-
-
monty@narttu.mysql.fi authored
More tests cases After merge fixes
-
- 29 Sep, 2003 1 commit
-
-
monty@narttu.mysql.fi authored
Add quoting for use `database` for mysqlbinlog Removed test ins0000001 Add support for --replace for exec in mysqltest Don't refer to install dir in mysqlbinlog.result
-
- 18 Aug, 2003 1 commit
-
-
monty@mashka.mysql.fi authored
Use server character set if --default-character-set is not used Added convert_string() for more efficient alloc+character-set convert of strings
-
- 18 Jul, 2003 1 commit
-
-
monty@narttu.mysql.fi authored
Fixed memory overrun when doing REPAIR on table with multi-part auto_increment key where one part was a packed CHAR
-
- 03 Jul, 2003 1 commit
-
-
monty@narttu.mysql.fi authored
Tests cleanup (put drop database first in tests)
-
- 01 Jul, 2003 1 commit
-
-
Sinisa@sinisa.nasamreza.org authored
-