An error occurred fetching the project authors.
- 21 Jun, 2006 1 commit
-
-
lars@mysql.com authored
-
- 19 Jun, 2006 1 commit
-
-
lars@mysql.com authored
-
- 15 Jun, 2006 1 commit
-
-
lars@mysql.com authored
-
- 31 May, 2006 1 commit
-
-
jani@ua141d10.elisa.omakaista.fi authored
-
- 29 May, 2006 2 commits
-
-
msvensson@neptunus.(none) authored
-
ramil@mysql.com authored
-
- 26 May, 2006 1 commit
-
-
grog@mysql.com authored
Get output from modified test (dropping t1). mysqldump.test: Drop t1 at end so that the next test doesn't trip over it.
-
- 25 May, 2006 1 commit
-
-
grog@mysql.com authored
-
- 19 May, 2006 1 commit
-
-
ramil@mysql.com authored
-
- 11 May, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
- Check that length of value is longer than 1 before decrementing length by 2. - Backport from 5.0, make it possible to use my_print_defaults in tests
-
- 10 May, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
-
- 04 May, 2006 2 commits
-
-
monty@mysql.com authored
Remove compiler warnings Fix some broken tests Workaround for syncronization bug in NDB (Bug #16445)
-
tnurnberg@mysql.com authored
mysqldump / SHOW CREATE TABLE will show the NEXT available value for the PK, rather than the *first* one that was available (that named in the original CREATE TABLE ... AUTO_INCREMENT = ... statement). This should produce correct and robust behaviour for the obvious use cases -- when no data were inserted, then we'll produce a statement featuring the same value the original CREATE TABLE had; if we dump with values, INSERTing the values on the target machine should set the correct next_ID anyway (and if not, we'll still have our AUTO_INCREMENT = ... to do that). Lastly, just the CREATE statement (with no data) for a table that saw inserts would still result in a table that new values could safely be inserted to). There seems to be no robust way however to see whether the next_ID field is > 1 because it was set to something else with CREATE TABLE ... AUTO_INCREMENT = ..., or because there is an AUTO_INCREMENT column in the table (but no initial value was set with AUTO_INCREMENT = ...) and then one or more rows were INSERTed, counting up next_ID. This means that in both cases, we'll generate an AUTO_INCREMENT = ... clause in SHOW CREATE TABLE / mysqldump. As we also show info on, say, charsets even if the user did not explicitly give that info in their own CREATE TABLE, this shouldn't be an issue. As per above, the next_ID will be affected by any INSERTs that have taken place, though. This /should/ result in correct and robust behaviour, but it may look non-intuitive to some users if they CREATE TABLE ... AUTO_INCREMENT = 1000 and later (after some INSERTs) have SHOW CREATE TABLE give them a different value (say, CREATE TABLE ... AUTO_INCREMENT = 1006), so the docs should possibly feature a caveat to that effect. It's not very intuitive the way it works now (with the fix), but it's *correct*. We're not storing the original value anyway, if we wanted that, we'd have to change on-disk representation? If we do dump/load cycles with empty DBs, nothing will change. This changeset includes an additional test case that proves that tables with rows will create the same next_ID for AUTO_INCREMENT = ... across dump/restore cycles. Confirmed by support as likely solution for client's problem.
-
- 10 Mar, 2006 1 commit
-
-
anozdrin@mysql.com authored
Now DEFINER-clause in stored routines is expected to appear in 5.0.20 release, not in 5.0.19. as it was supposed before.
-
- 09 Mar, 2006 1 commit
-
-
cmiller@calliope.local authored
the '-E' or '--events' flag. (Closes Bug#16853 and Bug#17714.) WARNING: At present, these tests fail due to b*g number 18078.
-
- 02 Mar, 2006 1 commit
-
-
anozdrin@mysql.com authored
The idea is to add DEFINER-clause in CREATE PROCEDURE and CREATE FUNCTION statements. Almost all support of definer in stored routines had been already done before this patch. NOTE: this patch changes behaviour of dumping stored routines in mysqldump. Before this patch, mysqldump did not dump DEFINER-clause for stored routines and this was documented behaviour. In order to get full information about stored routines, one should have dumped mysql.proc table. This patch changes this behaviour, so that DEFINER-clause is dumped. Since DEFINER-clause is not supported in CREATE PROCEDURE | FUNCTION statements before this patch, the clause is covered by additional version-specific comments.
-
- 24 Feb, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
-
- 22 Feb, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
-
- 21 Feb, 2006 2 commits
-
-
msvensson@neptunus.(none) authored
Bug#14857 Reading dump files with single statement stored routines fails.Bug #14857 Reading dump files with single statement stored routines fails. - Add tests, fixed by patch for 16878
-
msvensson@neptunus.(none) authored
- Add comments with embeded veriosn info around the parts of the view syntax that are only supported by a certain version of MySQL Server
-
- 20 Feb, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
-
- 17 Feb, 2006 2 commits
-
-
msvensson@neptunus.(none) authored
- Disable --use-threads option in 5.1.7
-
msvensson@neptunus.(none) authored
Evaluate commands passed to "exec" and "system" to expand any $variables before executing command.
-
- 14 Feb, 2006 1 commit
-
-
brian@zim.tangent.org authored
Added --silent option andd just test results via select. This will keep down the appearance of non deterministic responses. This is for bug#17384
-
- 13 Feb, 2006 1 commit
-
-
brian@zim.tangent.org authored
Adding thread support for mysqlimport. You can now specify a number of threads to use and it will thread the loading of the database. Anyone who has had to go through the pain of loading the database will immediatly get the reason for this.
-
- 09 Feb, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
- Pass "in_comment" variable on to new lex in sp_head::reset_lex - Add testcases for dumping and reloading trigger without BEGIN/END
-
- 12 Jan, 2006 1 commit
-
-
anozdrin@mysql.com authored
-
- 10 Jan, 2006 1 commit
-
-
anozdrin@mysql.com authored
There are two main idea of this fix: - introduce a common function for server and client to split user value (<user name>@<host name>) into user name and host name parts; - dump DEFINER clause in correct format in mysqldump.
-
- 31 Dec, 2005 1 commit
-
-
bar@mysql.com authored
- Encoding itself, implemented as a charset "filename". Originally planned to use '.' as an escape character, but now changed to '@' for two reasons: "ls" does not return file names starting with '.' considering them as a kind of hidden files; some platforms do not allow several dots in a file name. - replacing many calls of my_snprintf() and strnxmov() to the new build_table_filename(). - Adding MY_APPEND_EXT mysys flag, to append an extention rather that replace it. - Replacing all numeric constants in fn_format flag arguments to their mysys definitions, e.g. MY_UNPACK_FILENAME, - Predictability in several function/methods: when a table name can appear with or withot .frm extension. Some functions/methods were changed so accept names strictly with .frm, other - strictly without .frm extensions. Several DBUG_ASSERTs were added to check whether an extension is passed. Many files: table name to file name encoding mysql_priv.h: Prototypes for new table name encoding tools. ctype-utf8.c: Implementing "filename" charset for table name to file name encoding. row0mysql.c: Fixing table name prefix. mf_format.c: Adding MY_APPEND_EXT processing. Many files: Fixing tests. my_sys.h: Adding new flag to append rather than replace an extension. m_ctype.h: Adding "filename" charset definition.
-
- 02 Dec, 2005 1 commit
-
-
gluh@eagle.intranet.mysql.r18.ru authored
-issue more correct message for incorrect date|datetime|time values -ER_WARN_DATA_OUT_OF_RANGE message is changed -added new error message
-
- 01 Dec, 2005 1 commit
-
-
jimw@mysql.com authored
-
- 24 Nov, 2005 3 commits
-
-
brian@zim.(none) authored
-
brian@zim.(none) authored
Its funny, I am reading through the forums and someone asks "Can I please have a REPLACE INTO, instead an INSERT INTO?" and I remember how often I have used a sed script to modify MySQL dumps to have exactly that. So, use --replace and instead of getting INSERT INTO you will INSTEAD get REPLACE INTO. Buyer beward, REPLACE is a MySQL SQL, so you will not end up with a dump that can be used for other databases. Though I hear you could just use a sed line to modify it back :)
-
jimw@mysql.com authored
--hex-blob is used. (Bug #13318)
-
- 21 Nov, 2005 1 commit
-
-
aivanov@mysql.com authored
statement for tables created in the IGNORE_SPACE sql mode.
-
- 10 Nov, 2005 2 commits
-
-
anozdrin@mysql.com authored
checks on trigger activation)
-
ramil@mysql.com authored
-
- 04 Nov, 2005 1 commit
-
-
monty@mysql.com authored
(Caused sp-security to fail)
-
- 27 Oct, 2005 1 commit
-
-
monty@mysql.com authored
Cleaned up xxxx_gis.test's and made gis_generic.inc independent of ndb (Note that archive_gis.test fails, but this is independent of this patch)
-
- 25 Oct, 2005 1 commit
-
-
patg@krsna.patg.net authored
Made change to mysqlimport to set character_set_database to binary to make importing various charsets/columns work correctly.
-