Commit graph

21 commits

Author SHA1 Message Date
jimw@rama.(none)
d18eacc71d Bug #19498: Inconsistent support for DEFAULT in TEXT columns
When a default of '' was specified for TEXT/BLOB columns, the specification
  was silently ignored. This is presumably to be nice to applications (or
  people) who generate their column definitions in a not-very-clever fashion.

  For clarity, doing this now results in a warning, or an error in strict
  mode.
2006-07-18 16:04:18 -07:00
ingo@mysql.com
968ba3c226 Merge mysql.com:/home/mydev/mysql-4.1-bug17877
into  mysql.com:/home/mydev/mysql-5.0-bug11824
2006-06-29 10:26:24 +02:00
ingo@mysql.com
d8499f2d8f Bug#17877 - Corrupted spatial index
CHECK TABLE could complain about a fully intact spatial index.
A wrong comparison operator was used for table checking. 
The result was that it checked for non-matching spatial keys. 
This succeeded if at least two different keys were present, 
but failed if only the matching key was present.

I fixed the key comparison.
2006-06-28 14:27:37 +02:00
jani@ua141d10.elisa.omakaista.fi
0410832526 Merge ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-4.1
into  ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-5.0
2006-05-04 18:35:58 +03:00
tnurnberg@mysql.com
5becb110e0 Bug#19025 4.1 mysqldump doesn't correctly dump "auto_increment = [int]"
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.
2006-05-04 03:12:51 +02:00
hf@deer.(none)
418a7bfcde Merge deer.(none):/home/hf/work/mysql-4.1.clean
into deer.(none):/home/hf/work/mysql-5.0.clean
2005-08-27 18:10:46 +05:00
hf@deer.(none)
13a23f70b9 Fix for bug #9465 (check table extended fails with SPATIAL) 2005-08-09 21:30:28 +05:00
monty@mishka.local
2d25da2a4b concurrent-insert can now be set to 2 for concurrent inserts when there is holes in the data file
myisam_max_extra_sort_file_size is depricated
Ensure that myisam_data_pointer_size is honoured when creating new MyISAM files
Changed default value of myisam_data_pointer_size from 4 to 6 to get rid of 'table-is-full' errors
2005-05-13 12:08:08 +03:00
hf@deer.(none)
054463f975 Fix for #6553 and #8776 (no errors on bad spatial data) 2005-04-29 20:23:02 +05:00
jimw@mysql.com
01ddc370f0 Enable warnings for 'no default' fields being set to default when they
are not specified in an insert. Most of these changes are actually to
clean up the test suite to either specify defaults to avoid warnings,
or add the warnings to the results. Related to bug #5986.
2005-01-14 17:09:35 -08:00
monty@mishka.local
4f4bbfc279 Merge with 4.1 2004-12-22 13:54:39 +02:00
hf@deer.(none)
192715dbbb Fix for bug #6516 (Server crash loading spatial data)
(after discussion with SerG)
2004-12-10 16:06:49 +04:00
hf@deer.(none)
e211b26330 Fix for bug #6755 (ALTER TABLE ENABLE KEYS corrupts spatial index) 2004-12-06 11:42:41 +04:00
monty@mishka.local
be4ca46fbe More fixes for strict mode:
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.
2004-10-02 22:20:08 +03:00
hf@deer.(none)
7cf1d2596b wl 1562 (To improve RTree indexes)
some changes to make code nicer
2004-06-02 19:11:57 +05:00
monty@mysql.com
43546e7a82 Moved reading of ranges from opt_range.cc to handler.cc
This gives the handler more optimization possiblities and is needed for NDB cluster
Fixed not-initialized memory error detected by valgrind
2004-04-08 13:58:06 +03:00
hf@deer.(none)
9edef96561 Fix for #2237 and #2490 (analyze and check for RTree keys)
Now checking of the RTree keys works without errors.
Worklog entry about appropriate checkup's routine for the RTree added
2004-02-19 17:22:38 +04:00
antony@ltantony.rdg.cyberkinetica.homeunix.net
fcf96dbb18 WorkLog#1323
Deprecate the use of TYPE=... Preferred syntax is ENGINE=
2003-12-10 04:31:42 +00:00
monty@mashka.mysql.fi
cab1dc628c CLIENT_MULTI_QUERIES -> CLIENT_MULTI_STATEMENTS
New multi-key-cache handling. This was needed becasue the old one didn't work reliable with MERGE tables.
ALTER TABLE table_name ... CHARACTER SET  ... now changes all char/varchar/text columns to the given character set
(One must use ALTER TABLE ... DEFAULT CHARACTER SET ... to change the default character set)
Fixed that have_compress is detected properly (fixes problems with func_compress.test on platforms without zlib)
New syntax for CACHE INDEX ('keys' is optional if no index name is given and one mentions the key cache name only ones)
Removed compiler warnings
Added mysql_set_server_option() to allow clients like PHP to easaily set/reset the multi-statement flag.
2003-11-18 13:47:27 +02:00
ram@mysql.r18.ru
0ccb7c3789 Should use GeometryFromWKB(). 2003-03-18 17:01:38 +04:00
ram@mysql.r18.ru
1e47a3f9a4 Test case for rtree indexes. 2003-03-12 16:52:02 +04:00