Commit graph

28 commits

Author SHA1 Message Date
gluh@eagle.intranet.mysql.r18.ru
2a07350854 ps_6bdb, ps_7ndb tests failure fix 2005-09-12 14:21:38 +05:00
monty@mishka.local
292aefeeca Fixed some test cases that was not forgotten in a recent patch 2005-07-19 19:47:54 +03:00
konstantin@mysql.com
62b8e6fdd1 A fix and a test case for Bug#9735.
No separate typecode for MEDIUMTEXT/LONGTEXT is added, as we
have no sound decision yet what typecodes and for what types are
sent by the server (aka what constitutes a distinct type in MySQL).
2005-07-14 15:13:23 +04:00
konstantin@mysql.com
6a5b215443 Fix broken test suite. 2005-06-09 18:00:50 +04:00
msvensson@neptunus.(none)
9471e922f1 Merge neptunus.(none):/home/msvensson/mysql/bug8807
into neptunus.(none):/home/msvensson/mysql/mysql-4.1-synced
2005-03-30 14:30:32 +02:00
msvensson@neptunus.(none)
382a8c0048 BUG#8807 Select crash server
- Add function Item_param::fix_fields which will update any subselect they are part of and indicate that the subsleect is not const during prepare phase, and thus should not be executed during prepare.
2005-03-30 12:14:37 +02:00
serg@serg.mylan
639c58bff7 mysql-test/r/ps_6bdb.result
followup - results fixed
2005-03-24 10:28:02 +01:00
bar@mysql.com
8cfe729678 1. Item now uses my_charset_bin by default,
not default_charset_into. It fixes the
problem that in some cases numbers where
treated as CHAR(N), not as BINARY(N), e.g.
wrong 'charsetnr' when sent to the client side.
2. IFNULL didn't aggregate argument charsets
and collations, so IFNULL(1,'a') produced
a CHAR(N). Now produces a BINARY(N).
3. SELECT PROCEDURE ANALIZE now returns
BINARY columns, which is much better than it worked
previously: CHAR with the default character set.
But in the future it's worth to fix the fields
'Field_name' and 'Optimal_fieldtype' to use UTF8,
and 'Min_value' and 'Max_value' to inherit their charsets
from the original items. But it is not important,
and BINARY(N) is OK for now.
4. Tests were fixed accordingly. No new tests were
made, as the old onces cover everything.
2005-01-18 17:41:06 +04:00
dlenev@brandersnatch.localdomain
cd98fcf4e9 Merged fixes for bug #7297 "Two digit year should be interpreted
correctly even with zero month and day" and bug #7515 "from_unixtime(0)
now returns NULL instead of the Epoch" into 4.1 tree.
2004-12-30 23:44:42 +03:00
mleich@mysql.com
3b5a741aff Small bug fix
ps-modify1 used the user variables @1, @2, @100 set within ps_query and 
           ps_modify. That architecture was wrong, because the dependence
           of ps_modify1 on ps_query and ps_modify makes the test script
           maintenance and the use of these test cases during bug fixing/
           debugging of single sub test cases very uncomfortable.
Therefore these user variables (@1, @2, @100) are also set within ps-modify1.

The result files of the test cases ps_2myisam, ps_3innodb, ps_4heap, ps_6bdb,
ps_7ndb will be affected by that change and show 3 additional lines, but
nothing else will change.
2004-12-13 21:00:43 +01:00
bar@mysql.com
8878c58fe2 Fixed thar proper charset was not set in Field_set::val_str() 2004-12-06 16:22:51 +04:00
bar@mysql.com
c51d7acfcc 1. When mixing NULL to a character string,
the result takes its charset/collation
attributes from the character string,
e.g.  SELECT func(NULL, _latin2'string')
now returns a latin2 result. This is
done by introducing a new derivation
(aka coercibility) level DERIVATION_IGNORABLE,
which is used with Item_null.
2. 'Pure' NULL is now BINARY(0), not CHAR(0).
I.e. NULL is now more typeless.
2004-11-10 14:05:28 +04:00
bar@mysql.com
5543f312b0 As it is wrong and confusing to associate any
character set with NULL, @a should be latin2
after this query sequence:

   SET @a=_latin2'string';
   SET @a=NULL;

I.e. the second query should not change the charset
to the current default value, but should keep the
original value assigned during the first query.
In order to do it, we don't copy charset
from the argument if the argument is NULL
and the variable has previously been initialized.
2004-11-05 13:37:36 +04:00
konstantin@mysql.com
e97a79f2ee Enable REPLACE ... SELECT in prepared statements. 2004-10-30 17:17:52 +04:00
tomas@poseidon.ndb.mysql.com
1b35f6b469 another order by fix for ndb 2004-10-11 20:58:48 +00:00
tomas@poseidon.ndb.mysql.com
a257686692 more order by fixes 2004-10-07 12:36:37 +00:00
tomas@poseidon.ndb.mysql.com
4afccd761b more order by for ndb 2004-10-07 09:51:30 +00:00
tomas@poseidon.ndb.mysql.com
690cdfc697 added order by to give same order results on different endian and different sized clusters 2004-10-07 09:27:39 +00:00
konstantin@mysql.com
07700678b0 Some of the recently pushed prepared statements
tests were disabled due to failures caused by floating point conversion
issues on optimized builds).
2004-09-28 21:44:42 +04:00
konstantin@mysql.com
d03f447f84 Results of WL#1856 "Conversion of client_test.c tests cases to mysqltest
if possible"
        - many new test cases
        - more and improved comments
      New files: t/ps_7ndb.test       test suite for NDB tables
                 r/ps_7ndb.result     expected results
                 include/ps_conv.inc  conversion test cases
+ review comments and fixes.
2004-09-25 19:08:02 +04:00
mleich@mysql.com
51d42739b9 These modifications were part of WL#1856 Conversion of client_test.c tests cases to mysqltest if possible
They are separated from the other WL#1856 stuff, because they improve the behaviour of the current tests.  

Make the result sets (order of rows) more predictable by using ORDER BY.
2004-09-20 13:10:47 +02:00
konstantin@mysql.com
4230eae857 A fix and test case for bug#5510 "inserting Null in AutoIncrement primary
key Column Fails".
2004-09-18 01:10:09 +04:00
bar@mysql.com
7c4ab566d2 Return character strings in table, type, possible_keys, key fields
of EXPLAIN SELECT, rather than binary strings.
2004-09-16 14:47:39 +05:00
konstantin@mysql.com
452b62b81a Fix the test case to make it more predictable (cause: 4.1.5 test failure
on intelxeon3 (Solaris x86))
2004-09-15 14:25:58 +04:00
pem@mysql.comhem.se
f0cd209373 Updated ps_6bdb.results. 2004-07-30 12:13:40 +02:00
serg@serg.mylan
555442bf6a fixed ORDER BY ?
new tests to ensure that prepared statement *really* work
(and that MySQL not picks up some number from arbitrary location
that happens to match the parameter's value)
2004-07-21 19:17:07 +02:00
bell@sanja.is.com.ua
41bd6aa4b6 do not assign values of left expression of IN/ANN/ANY subquery in case of PS preparation (BUG#4403) 2004-07-04 10:40:24 +03:00
gordon@zero.local.lan
7071d062c9 WL#1564 Intensive test of prepared statements via 'mysqltest' 2004-07-01 16:30:29 +02:00