1
0
mirror of https://github.com/MariaDB/server.git synced 2025-12-24 11:21:21 +03:00
Files
mariadb/mysql-test/t
Alexander Barkov 7f98714247 Bug#54916 GROUP_CONCAT + IFNULL truncates output
Problem: a few functions did not calculate their max_length correctly.
This is an after-fix for WL#2649 Number-to-string conversions".

Fix: changing the buggy functions to calculate max_length
using fix_char_length() introduced in WL#2649,
instead of setting max_length directly

  mysql-test/include/ctype_numconv.inc
     Adding new tests

  mysql-test/r/ctype_binary.result
     Adding new tests

  mysql-test/r/ctype_cp1251.result
     Adding new tests

  mysql-test/r/ctype_latin1.result
     Adding new tests

  mysql-test/r/ctype_ucs.result
     Adding new tests

  mysql-test/r/ctype_utf8.result
     Adding new tests

  mysql-test/t/ctype_utf8.test
    Including ctype_numconv

  sql/item.h
    - Introducing new method fix_char_length_ulonglong(),
    for the cases when length is potentially greater
    than UINT_MAX32. This method removes a few
    instances of duplicate code, e.g. in item_strfunc.cc.
    - Setting collation in Item_copy properly. This change
    fixes wrong metadata on client side in some cases, when
    "binary" instead of the real character set was reported.

  sql/item_cmpfunc.cc
    - Using fix_char_length() and max_char_length() methods,
    instead of direct access to max_length, to calculate
    item length properly.
    - Moving count_only_length() in COALESCE after
    agg_arg_charsets_for_string_result(). The old
    order was incorrect and led to wrong length
    calucation in case of multi-byte character sets.
    
  sql/item_func.cc
    Fixing that count_only_length() didn't work
    properly for multi-byte character sets.
    Using fix_char_length() and max_char_length()
    instead of direct access to max_length.

  sql/item_strfunc.cc
    - Using fix_char_length(), fix_char_length_ulonglong(),
    max_char_length() instead of direct access to max_length.
    - Removing wierd condition: "if (collation.collation->mbmaxlen > 0)",
    which is never FALSE.
2010-08-19 15:55:35 +04:00
..
2010-02-25 23:13:11 +04:00
2010-05-26 22:34:25 +08:00
2010-02-24 13:15:34 +04:00
2010-02-24 13:15:34 +04:00
2010-02-24 13:15:34 +04:00
2010-02-02 02:22:16 +03:00
2009-12-08 10:53:40 +03:00
2009-12-09 18:56:34 +03:00
2010-04-13 19:04:45 +04:00
2010-04-13 19:04:45 +04:00
2010-02-11 18:32:53 +01:00
2009-10-19 14:58:13 +02:00
2010-07-30 16:56:57 +03:00
2010-06-11 10:15:55 +02:00
2010-01-15 15:42:15 +04:00
2010-01-15 15:42:15 +04:00
2010-07-15 18:46:41 +03:00
2009-12-03 23:08:27 +03:00
2009-09-04 15:20:58 +02:00
2010-06-01 11:54:06 +04:00
2010-04-27 00:46:52 +04:00
2009-11-30 19:09:42 +03:00
2010-07-14 15:05:20 +03:00
2010-05-26 22:34:25 +08:00
2010-04-20 10:51:50 +02:00
2009-12-24 10:56:13 +03:00
2010-07-16 21:25:00 +03:00
2010-04-13 19:04:45 +04:00
2009-10-19 14:58:13 +02:00
2009-09-04 15:20:58 +02:00
2009-08-12 12:03:05 +02:00
2010-05-28 09:47:58 +04:00
2010-02-24 00:22:19 -07:00
2009-11-02 21:05:42 +01:00
2009-12-29 15:19:05 +03:00
2010-02-06 13:28:06 +03:00
2009-12-03 23:08:27 +03:00
2009-11-20 22:51:12 +03:00
2010-07-16 21:25:00 +03:00
2009-09-10 03:18:29 -06:00
2009-09-10 03:18:29 -06:00
2009-09-10 03:18:29 -06:00
2009-09-10 03:18:29 -06:00
2009-09-10 03:18:29 -06:00
2010-07-04 20:35:05 +01:00
2010-04-19 15:35:13 +02:00
2009-11-27 18:10:28 +02:00
2010-07-30 19:28:36 +04:00
2010-04-13 19:04:45 +04:00
2010-04-13 19:04:45 +04:00
2010-04-13 19:04:45 +04:00
2010-04-13 19:04:45 +04:00
2010-04-13 19:04:45 +04:00
2009-12-03 23:08:27 +03:00
2010-08-05 15:34:19 +03:00
2010-06-25 16:32:47 +03:00