Problems may happen when issuing DDL commands in the same transaction after CREATE COLLATION was issued [CORE3056] #3436
Labels
affect-version: 2.0.0
affect-version: 2.0.1
affect-version: 2.0.2
affect-version: 2.0.3
affect-version: 2.0.4
affect-version: 2.0.5
affect-version: 2.1.0
affect-version: 2.1.1
affect-version: 2.1.2
affect-version: 2.1.3
affect-version: 2.5 Alpha 1
affect-version: 2.5 Beta 1
affect-version: 2.5 Beta 2
affect-version: 2.5 RC1
affect-version: 2.5 RC2
affect-version: 3.0 Initial
component: charsets/collation
component: engine
fix-version: 3.0 Alpha 1
priority: major
qa: done with caveats
type: bug
Submitted by: @asfernandes
Relate to CORE2826
Is related to QA553
Relate to CORE4425
Test case adapted from Vlad's comment in CORE2826:
---------------
CREATE COLLATION UNICODE_NOPAD FOR UTF8 FROM UNICODE NO PAD;
--COMMIT; -- (1)
RECREATE TABLE tst1_nopad (
k1 VARCHAR(3) COLLATE UNICODE_NOPAD,
k2 INT,
k3 CHAR(1) COLLATE UNICODE_NOPAD,
PRIMARY KEY (k1, k2, k3)
);
COMMIT;
SHOW TABLE tst1_nopad;
---------------
Note, without COMMIT at point (1), fields of tst1_nopad will have collate UTF8!
Also, multiple CREATE COLLATION for the same charset raises unique violation error.
Commits: 08bbc59
====== Test Details ======
1. Results are identical on: LI-T3.0.0.31827 (64 bit) and WI-T3.0.0.31827 (32 bit).
2. Despite of ticket issue that it was fixed only in 3.0, following script works OK on also on 2.5
(tested on WI-V2.5.5.26861; differences are only in stderr).
3. ## TODO ###
Uncomment lines "--,constraint test_pk1 primary key" after CORE4783 will be fixed, and add
statement 'alter table drop constraint <PK>" before each DROP TABLE statements.
The text was updated successfully, but these errors were encountered: