1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-24 19:42:23 +03:00
Commit Graph

33 Commits

Author SHA1 Message Date
a88c71b294 MDEV-35041 Simple comparison causes "Illegal mix of collations" even with default server settings
The task "MDEV-25829 Change default Unicode collation to uca1400_ai_ci"
previously changed collation derivation for string user variables
from DERIVATION_EXPLICIT to DERIVATION_COERCIBLE, to resolve illegal
collation mix conflicts between table columns and user variables
when they have different collations.

However, DERIVATION_COERCIBLE was a wrong choice because it caused
conflicts between string literals and user variables when they have
different collations.

Adding a new collation derivation level DERIVATION_USERVAR.
This makes the collation of a user variable:
- weaker than a table column (like it was intended by MDEV-25829)
- but stronger than a literal (like it was in pre-MDEV-25829)

Cleanup in sql_type.h:
  Removing the line "- BINARY(expr)" from the before-DERIVATION_CAST
  comment, as it was on a wrong place. It's also listed on the correct
  place before DERIVATION_IMPLICIT.
2024-10-28 16:30:49 +04:00
36eba98817 MDEV-19123 Change default charset from latin1 to utf8mb4
Changing the default server character set from latin1 to utf8mb4.
2024-07-11 10:21:07 +04:00
903b5d6a83 MDEV-25829 Change default Unicode collation to uca1400_ai_ci
Step#3 The main patch
2024-05-24 15:50:05 +04:00
a3117c7983 MDEV-25829 Change default Unicode collation to uca1400_ai_ci
Step#2 - Adding a new collation derivation level for CAST and CONVERT.

Now character string cast functions:
  - CAST(string_expr AS CHAR)
  - CONVERT(expr USING charset_name)

have a new collation derivation level between:

  - string literals
  - utf8 metadata functions, e.g. user() and database()

Before the change these cast functions had collation derivation equal
to table columns, which caused more illegal mix of collation conflicts.

Note, binary string cast functions:
  - BINARY(expr)
  - CAST(string_expr AS BINARY)
  - CONVERT(expr USING binary)
did not change their collation derivation, to preserve the behaviour of
queries like these:
SELECT database()=BINARY'test';
SELECT user()=CAST('root' AS BINARY);
SELECT current_role()=CONVERT('role' USING binary);

Derivation levels after the change look as follows:

  DERIVATION_IGNORABLE= 7, // Explicit NULL

  DERIVATION_NUMERIC= 6,   // Numbers in string context,
                           // Numeric user variables
                           // CAST(numeric_expr AS CHAR)

  DERIVATION_COERCIBLE= 5, // Literals, string user variables

  DERIVATION_CAST= 4,      // CAST(string_expr AS CHAR),
                           // CONVERT(string_expr USING cs)

  DERIVATION_SYSCONST= 3,  // utf8 metadata functions, e.g. user(), database()
  DERIVATION_IMPLICIT= 2,  // Table columns, SP variables, BINARY(expr)
  DERIVATION_NONE= 1,      // A mix (e.g. CONCAT) of two differrent collations
  DERIVATION_EXPLICIT= 0   // An explicit COLLATE clause
2024-05-24 15:37:47 +04:00
6ffe9ad0d4 Merge 10.9 into 10.10 2023-01-13 11:45:57 +02:00
1e04cafcba Merge 10.6 into 10.7 2023-01-13 10:47:56 +02:00
3386b30975 Merge 10.5 into 10.6 2023-01-13 10:45:41 +02:00
1e6ad0ce13 don't set default value in temp table if NO_DEFAULT_VALUE_FLAG
when an internal temporary table field is created from a real field,
a new temp field should only copy a default from the source field
when the latter has it
2023-01-09 18:06:06 +01:00
5e996fbad9 Merge 10.9 into 10.10 2022-09-21 10:59:56 +03:00
7c7ac6d4a4 Merge 10.6 into 10.7 2022-09-21 09:33:07 +03:00
44fd2c4b24 Merge 10.5 into 10.6 2022-09-20 16:53:20 +03:00
18795f5512 Merge 10.3 into 10.4 2022-09-13 16:36:38 +03:00
f1544424de MDEV-29446 Change SHOW CREATE TABLE to display default collation 2022-09-12 22:10:39 +04:00
45e0373a78 MDEV-28632 Change default of explicit_defaults_for_timestamp to ON 2022-08-10 15:03:22 +02:00
fd132be117 Merge branch '10.6' into 10.7 2022-05-11 11:25:33 +02:00
3bc98a4ec4 Merge branch '10.5' into 10.6 2022-05-10 14:01:23 +02:00
a8e57906d1 10.4 specific fixes for DEFAULT() 2022-05-09 12:21:02 +02:00
a2dd86df9c cleanup: test 2022-05-09 12:20:08 +02:00
a70a1cf3f4 Merge branch '10.3' into 10.4 2022-05-08 23:03:08 +02:00
6f741eb6e4 Merge branch '10.2' into 10.3 2022-05-07 11:48:15 +02:00
6f6c74b0d1 Merge branch '10.2' into 10.3 2022-04-21 10:05:50 +02:00
a398fcbff6 MDEV-26635 ROW_NUMBER is not 0 for errors not caused because of rows 2021-10-26 17:29:40 +02:00
a8379e53e8 Merge 10.5 into 10.6
The changes to galera.galear_var_replicate_myisam_on
in commit d9b933bec6
are omitted due to conflicts
with commit 27d66d644c.
2021-10-13 13:28:12 +03:00
a736a3174a Merge 10.3 into 10.4 2021-10-13 12:03:32 +03:00
4a7dfda373 Merge 10.2 into 10.3 2021-10-13 11:38:21 +03:00
2fdb556e04 MDEV-8334: Rename utf8 to utf8mb3
This patch changes the main name of 3 byte character set from utf8 to
utf8mb3. New old_mode UTF8_IS_UTF8MB3 is added and set TRUE by default,
so that utf8 would mean utf8mb3. If not set, utf8 would mean utf8mb4.
2021-05-19 06:48:36 +02:00
e841957416 Merge branch '10.3' into 10.4 2021-02-23 09:25:57 +01:00
8db5274dce MDEV-22703 DEFAULT() on a BLOB column can overwrite the default record
This can cause crashes when accessing already released memory

The issue was the Item_default created a internal field, pointing to
share->default_values, to be used with the DEFAULT() function.
This does not work for BLOB fields as these are freed at end of query.
Fixed by storing BLOB field data inside and area allocated by
Item_default_value,  like we do for nondeterministic default values.
2021-02-21 20:43:28 +02:00
244f0e6dd8 Merge branch '10.3' into 10.4 2019-09-06 11:53:10 +02:00
537f8594a6 Merge 10.2 into 10.3 2019-09-04 17:52:04 +03:00
8c8bee0a56 MDEV-10307 CAST(11068046444225730969 AS SIGNED) does not return a warning 2019-04-30 15:51:49 +04:00
c3a6c683e2 Merge 10.2 into 10.3 2019-03-25 11:03:19 +02:00
a7abddeffa Create 'main' test directory and move 't' and 'r' there 2018-03-29 13:59:44 +03:00