summaryrefslogtreecommitdiff
path: root/mysql-test/suite/ibmdb2i
Commit message (Collapse)AuthorAgeFilesLines
* BUG#58079 - Remove the IBM DB2 storage engineSergey Vojtovich2010-11-1121-1548/+0
|
* Bug#49329 example (and other) engines use wrong collation for open tables hashV Narayanan2009-12-112-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | This fix changes the character set used within the IBMDB2I handler to hash table names to information about open tables. Previously, tables with names that differed only in letter case would hash to the same data structure. This caused incorrect behavior or errors when two such tables were in use simultaneously. mysql-test/suite/ibmdb2i/r/ibmdb2i_bug_49329.result: Bug#49329 example (and other) engines use wrong collation for open tables hash Result file for the test case. mysql-test/suite/ibmdb2i/t/ibmdb2i_bug_49329.test: Bug#49329 example (and other) engines use wrong collation for open tables hash Test case for the bug fix. storage/ibmdb2i/ha_ibmdb2i.cc: Bug#49329 example (and other) engines use wrong collation for open tables hash change the character set used within the IBMDB2I handler to hash table names to information about open tables.
* Bug#45983 ibmdb2i_create_index_option=1 not working for primary keyV Narayanan2009-07-082-0/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With ibmdb2i_create_index_option set to 1, creating an IBMDB2I table with a primary key should produce an additional index that uses EBCDIC hexadecimal sorting. However, this does not work. Adding indexes that are not primary keys does work. The ibmdb2i_create_index_option should be honoured when creating a table with a primary key. This patch adds code to the create() function to check for the value of the ibmdb2i_create_index_option variable and, when appropriate, to generate a *HEX-based shadow index in DB2 for the primary key. Previously this behavior was limited to secondary indexes. Additionally, this patch restricts the creation of shadow indexes to cases in which a non-*HEX sort sequence is used, as the documentation for ibmdb2i_create_index_option describes. Previously, the shadow index would in some cases be created even when the MySQL-specific index used *HEX sorting, leading to redundant indexes. Finally, the code used to generate the list of fields for indexes and the code used to generate the SQL statement for the shadow indexes has been refactored into individual functions. mysql-test/suite/ibmdb2i/r/ibmdb2i_bug_45983.result: Bug#45983 ibmdb2i_create_index_option=1 not working for primary key Result file for the test case. mysql-test/suite/ibmdb2i/t/ibmdb2i_bug_45983.test: Bug#45983 ibmdb2i_create_index_option=1 not working for primary key Add tests to verify that the ibmdb2i_create_index_option is being honoured when creating a table with a primary key. storage/ibmdb2i/ha_ibmdb2i.cc: Bug#45983 ibmdb2i_create_index_option=1 not working for primary key - Add code to the create() function to check for the value of the ibmdb2i_create_index_option variable and, when appropriate, to generate a *HEX-based shadow index in DB2 for the primary key. - Restrict the creation of shadow indexes to cases in which a non-*HEX sort sequence is used. - Refractor code used to generate the list of fields for indexes and the code used to generate the SQL statement for the shadow indexes into individual functions. storage/ibmdb2i/ha_ibmdb2i.h: Bug#45983 ibmdb2i_create_index_option=1 not working for primary key Add function prototypes for the functions that. - Generate the list of fields for indexes - Generate the SQL statement for the shadow indexes
* Bug#45803 Inaccurate estimates for partial key values with IBMDB2IV Narayanan2009-07-062-0/+1248
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some collations were causing IBMDB2I to report inaccurate key range estimations to the optimizer for LIKE clauses that select substrings. This can be seen by running EXPLAIN. This problem primarily affects multi-byte and unicode character sets. This patch involves substantial changes to several modules. There are a number of problems with the character set and collation handling. These problems have been or are being fixed, and a comprehensive test has been included which should provide much better coverage than there was before. This test is enabled only for IBM i 6.1, because that version has support for the greatest number of collations. mysql-test/suite/ibmdb2i/r/ibmdb2i_collations.result: Bug#45803 Inaccurate estimates for partial key values with IBMDB2I result file for test case. mysql-test/suite/ibmdb2i/t/ibmdb2i_collations.test: Bug#45803 Inaccurate estimates for partial key values with IBMDB2I Tests for character sets and collations. This test is enabled only for IBM i 6.1, because that version has support for the greatest number of collations. storage/ibmdb2i/db2i_conversion.cc: Bug#45803 Inaccurate estimates for partial key values with IBMDB2I - Added support in convertFieldChars to enable records_in_range to determine how many substitute characters were inserted and to suppress conversion warnings. - Fixed bug which was causing all multi-byte and Unicode fields to be created as UTF16 (CCSID 1200) fields in DB2. The corrected code will now create UCS2 fields as UCS2 (CCSID 13488), UTF8 fields (except for utf8_general_ci) as UTF8 (CCSID 1208), and all other multi-byte or Unicode fields as UTF16. This will only affect tables that are newly created through the IBMDB2I storage engine. Existing IBMDB2I tables will retain the original CCSID until recreated. The existing behavior is believed to be functionally correct, but it may negatively impact performance by causing unnecessary character conversion. Additionally, users accessing IBMDB2I tables through DB2 should be aware that mixing tables created before and after this change may require extra type casts or other workarounds. For this reason, users who have existing IBMDB2I tables using a Unicode collation other than utf8_general_ci are encouraged to recreate their tables (e.g. ALTER TABLE t1 ENGINE=IBMDB2I) in order to get the updated CCSIDs associated with their DB2 tables. - Improved error reporting for unsupported character sets by forcing a check for the iconv conversion table at table creation time, rather than at data access time. storage/ibmdb2i/db2i_myconv.h: Bug#45803 Inaccurate estimates for partial key values with IBMDB2I Fix to set errno when iconv fails. storage/ibmdb2i/db2i_rir.cc: Bug#45803 Inaccurate estimates for partial key values with IBMDB2I Significant improvements were made to the records_in_range code that handles partial length string data in keys for optimizer plan estimation. Previously, to obtain an estimate for a partial key value, the implementation would perform any necessary character conversion and then attempt to determine the unpadded length of the partial key by searching for the minimum or maximum sort character. While this algorithm was sufficient for most single-byte character sets, it did not treat Unicode and multi-byte strings correctly. Furthermore, due to an operating system limitation, partial keys having UTF8 collations (ICU sort sequences in DB2) could not be estimated with this method. With this patch, the code no longer attempts to explicitly determine the unpadded length of the key. Instead, the entire key is converted (if necessary), including padding, and then passed to the operating system for estimation. Depending on the source and target character sets and collations, additional logic is required to correctly handle cases in which MySQL uses unconvertible or differently -weighted values to pad the key. The bulk of the patch exists to implement this additional logic. storage/ibmdb2i/ha_ibmdb2i.h: Bug#45803 Inaccurate estimates for partial key values with IBMDB2I The convertFieldChars declaration was updated to support additional optional behaviors.
* Bug#45793 macce charset causes error with IBMDB2IV Narayanan2009-07-022-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | Creating an IBMDB2I table with the macce character set is successful, but any attempt to insert data into the table was failing. This was happening because the character set name "macce" is not a valid iconv descriptor for IBM i PASE. This patch adds an override to convertTextDesc to use the equivalent valid iconv descriptor "IBM-1282" instead. mysql-test/suite/ibmdb2i/r/ibmdb2i_bug_45793.result: Bug#45793 macce charset causes error with IBMDB2I Result file for the test case. mysql-test/suite/ibmdb2i/t/ibmdb2i_bug_45793.test: Bug#45793 macce charset causes error with IBMDB2I Add a testcase for the macce charater set. storage/ibmdb2i/db2i_charsetSupport.cc: Bug#45793 macce charset causes error with IBMDB2I The character set name "macce" is not a valid iconv descriptor for IBM i PASE. Add an override to convertTextDesc to use the equivalent valid iconv descriptor "IBM-1282" instead.
* Bug#45196 Some collations do not sort correctly with IBMDB2IV Narayanan2009-06-292-0/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some collations--including cp1250_czech_cs,latin2_czech_cs, ucs2/utf8_czech_ci, ucs2/utf8_danish_ci--are not being sorted correctly by the IBMDB2I storage engine. This was being caused because the sort order used by DB2 is incompatible with the order expected by MySQL. This patch removes support for the cp1250_czech_cs and latin2_czech_cs collations because it has been determined that the sort order used by DB2 is incompatible with the order expected by MySQL. Users needing a czech collation with IBMDB2I are encouraged to use a Unicode-based collation instead of these single-byte collations. This patch also modifies the DB2 sort sequence used for ucs2/utf8_czech_ci and ucs2/utf8_danish_ci collations to better match the sorting expected by MySQL. This will only affect indexes or tables that are newly created through the IBMDB2I storage engine. Existing IBMDB2I tables will retain the old sort sequence until recreated. mysql-test/suite/ibmdb2i/r/ibmdb2i_bug_45196.result: Bug#45196 Some collations do not sort correctly with IBMDB2I Result file for the test case. mysql-test/suite/ibmdb2i/t/ibmdb2i_bug_45196.test: Bug#45196 Some collations do not sort correctly with IBMDB2I Adding tests for testing the sort order with the modified collations. storage/ibmdb2i/db2i_collationSupport.cc: Bug#45196 Some collations do not sort correctly with IBMDB2I Remove the support for the cp1250_czech_cs and latin2_czech_cs collations because it has been determined that the sort order used by DB2 is incompatible with the order expected by MySQL. Users needing a czech collation with IBMDB2I are encouraged to use a Unicode-based collation instead of these single-byte collations. This patch also modifies the DB2 sort sequence used for ucs2/utf8_czech_ci and ucs2/utf8_danish_ci collations to better match the sorting expected by MySQL. This will only affect indexes or tables that are newly created through the IBMDB2I storage engine. Existing IBMDB2I tables will retain the old sort sequence until recreated.
* Bug#44610 RCDFMT clause requested when creating DB2 tableNarayanan V2009-05-172-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to better support the usage of IBMDB2I tables from within RPG programs, the storage engine should ensure that the RCDFMT name is consistent and predictable for DB2 tables. This patch appends a "RCDFMT <name>" clause to the CREATE TABLE statement that is passed to DB2. <name> is generated from the original name of the table itself. This ensures a consistent and deterministic mapping from the original table. For the sake of simplicity only the alpha-numeric characters are preserved when generating the new name, and these are upper-cased; other characters are replaced with an underscore (_). Following DB2 system identifier rules, the name always begins with an alpha-character and has a maximum of ten characters. If no usable characters are found in the table name, the name X is used. mysql-test/suite/ibmdb2i/r/ibmdb2i_bug_44610.result: Bug#44610 RCDFMT clause requested when creating DB2 table Result file for the test case. mysql-test/suite/ibmdb2i/t/ibmdb2i_bug_44610.test: Bug#44610 RCDFMT clause requested when creating DB2 table Test case that confirms that the names that are being generated are valid. storage/ibmdb2i/ha_ibmdb2i.cc: Bug#44610 RCDFMT clause requested when creating DB2 table This patch appends a "RCDFMT <name>" clause to the CREATE TABLE statement that is passed to DB2. <name> is generated from the original name of the table itself. This ensures a consistent and deterministic mapping from the original table. storage/ibmdb2i/ha_ibmdb2i.h: Bug#44610 RCDFMT clause requested when creating DB2 table This patch appends a "RCDFMT <name>" clause to the CREATE TABLE statement that is passed to DB2. <name> is generated from the original name of the table itself. This ensures a consistent and deterministic mapping from the original table.
* Bug#44232 Error msg should be improved when collation not supported.Narayanan V2009-05-143-0/+32
| | | | | | | | | | | | checking in a test case that will reproduce the error on v5r4. mysql-test/suite/ibmdb2i/include/have_i54.inc: Bug#44232 Error msg should be improved when collation not supported. mysql-test/suite/ibmdb2i/r/ibmdb2i_bug_44232.result: Bug#44232 Error msg should be improved when collation not supported. mysql-test/suite/ibmdb2i/t/ibmdb2i_bug_44232.test: Bug#44232 Error msg should be improved when collation not supported.
* Importing test cases for IBMDB2INarayanan V2009-04-146-0/+59
The current patch -- Adds the ibmdb2i suite -- related include(.inc) files -- tests for Bug#44020 and Bug#44025