- developers - lists.mariadb.org

Re: [Maria-developers] [Commits] f28af02: Removed HW acceleration for big endian checksum
by Marko Mäkelä 23 Nov '17

23 Nov '17

Looks OK to me. This can only slightly punish the very few people who are upgrading from a buggy MySQL 5.6 or MariaDB 10.0 or 10.1 installation on a big-endian machine (such as SPARC) into a newer version. And those users could invoke innochecksum to rewrite the page checksums. On Thu, Nov 23, 2017 at 12:57 PM, Sergey Vojtovich <svoj(a)mariadb.org> wrote: > revision-id: f28af027a0439d760c6d26eb67a932e97eb665d7 > (mariadb-10.3.2-66-gf28af02) > parent(s): b2571e534f9eed873cc9b1ce5f48b109c1ee0fcc > committer: Sergey Vojtovich > timestamp: 2017-11-23 14:53:16 +0400 > message: > > Removed HW acceleration for big endian checksum > > Big endian checksum is needed to workaround 10+ years old bug, where > checksum > was calculated incorrectly on big endian hardware. We can still checksum > such > tablespaces using software implementation of CRC32. > > --- > storage/innobase/include/ut0crc32.h | 4 +- > storage/innobase/ut/ut0crc32.cc | 89 +----------------------------- > ------- > 2 files changed, 3 insertions(+), 90 deletions(-) > > diff --git a/storage/innobase/include/ut0crc32.h > b/storage/innobase/include/ut0crc32.h > index 509ac09..527a3e81 100644 > --- a/storage/innobase/include/ut0crc32.h > +++ b/storage/innobase/include/ut0crc32.h > @@ -47,9 +47,9 @@ typedef uint32_t (*ut_crc32_func_t)(const byte* > ptr, ulint len); > /** Pointer to CRC32 calculation function. */ > extern ut_crc32_func_t ut_crc32; > > -/** Pointer to CRC32 calculation function, which uses big-endian byte > order > +/** CRC32 calculation function, which uses big-endian byte order > when converting byte strings to integers internally. */ > -extern ut_crc32_func_t ut_crc32_legacy_big_endian; > +extern uint32_t ut_crc32_legacy_big_endian(const byte* buf, ulint len); > > extern const char* ut_crc32_implementation; > > diff --git a/storage/innobase/ut/ut0crc32.cc b/storage/innobase/ut/ > ut0crc32.cc > index 6383e6d..36c52b7 100644 > --- a/storage/innobase/ut/ut0crc32.cc > +++ b/storage/innobase/ut/ut0crc32.cc > @@ -89,10 +89,6 @@ mysys/my_perf.c, contributed by Facebook under the > following license. > /** Pointer to CRC32 calculation function. */ > ut_crc32_func_t ut_crc32; > > -/** Pointer to CRC32 calculation function, which uses big-endian byte > order > -when converting byte strings to integers internally. */ > -ut_crc32_func_t ut_crc32_legacy_big_endian; > - > /** Text description of CRC32 implementation */ > const char* ut_crc32_implementation; > > @@ -238,37 +234,6 @@ ut_crc32_64_hw( > *len -= 8; > } > > -/** Calculate CRC32 over 64-bit byte string using a hardware/CPU > instruction. > -The byte string is converted to a 64-bit integer using big endian byte > order. > -@param[in,out] crc crc32 checksum so far when this function is called, > -when the function ends it will contain the new checksum > -@param[in,out] data data to be checksummed, the pointer will be > advanced > -with 8 bytes > -@param[in,out] len remaining bytes, it will be decremented with 8 */ > -inline > -void > -ut_crc32_64_legacy_big_endian_hw( > - uint32_t* crc, > - const byte** data, > - ulint* len) > -{ > - uint64_t data_int = *reinterpret_cast<const > uint64_t*>(*data); > - > -#ifndef WORDS_BIGENDIAN > - data_int = ut_crc32_swap_byteorder(data_int); > -#else > - /* Currently we only support x86_64 (little endian) CPUs. In case > - some big endian CPU supports a CRC32 instruction, then maybe we > will > - NOT need a byte order swap here. */ > -#error Dont know how to handle big endian CPUs > -#endif /* WORDS_BIGENDIAN */ > - > - *crc = ut_crc32_64_low_hw(*crc, data_int); > - > - *data += 8; > - *len -= 8; > -} > - > /** Calculates CRC32 using hardware/CPU instructions. > @param[in] buf data over which to calculate CRC32 > @param[in] len data length > @@ -355,56 +320,6 @@ ut_crc32_hw( > > return(~crc); > } > - > -/** Calculates CRC32 using hardware/CPU instructions. > -This function uses big endian byte ordering when converting byte sequence > to > -integers. > -@param[in] buf data over which to calculate CRC32 > -@param[in] len data length > -@return CRC-32C (polynomial 0x11EDC6F41) */ > -uint32_t > -ut_crc32_legacy_big_endian_hw( > - const byte* buf, > - ulint len) > -{ > - uint32_t crc = 0xFFFFFFFFU; > - > - /* Calculate byte-by-byte up to an 8-byte aligned address. After > - this consume the input 8-bytes at a time. */ > - while (len > 0 && (reinterpret_cast<uintptr_t>(buf) & 7) != 0) { > - ut_crc32_8_hw(&crc, &buf, &len); > - } > - > - while (len >= 128) { > - /* This call is repeated 16 times. 16 * 8 = 128. */ > - ut_crc32_64_legacy_big_endian_hw(&crc, &buf, &len); > - ut_crc32_64_legacy_big_endian_hw(&crc, &buf, &len); > - ut_crc32_64_legacy_big_endian_hw(&crc, &buf, &len); > - ut_crc32_64_legacy_big_endian_hw(&crc, &buf, &len); > - ut_crc32_64_legacy_big_endian_hw(&crc, &buf, &len); > - ut_crc32_64_legacy_big_endian_hw(&crc, &buf, &len); > - ut_crc32_64_legacy_big_endian_hw(&crc, &buf, &len); > - ut_crc32_64_legacy_big_endian_hw(&crc, &buf, &len); > - ut_crc32_64_legacy_big_endian_hw(&crc, &buf, &len); > - ut_crc32_64_legacy_big_endian_hw(&crc, &buf, &len); > - ut_crc32_64_legacy_big_endian_hw(&crc, &buf, &len); > - ut_crc32_64_legacy_big_endian_hw(&crc, &buf, &len); > - ut_crc32_64_legacy_big_endian_hw(&crc, &buf, &len); > - ut_crc32_64_legacy_big_endian_hw(&crc, &buf, &len); > - ut_crc32_64_legacy_big_endian_hw(&crc, &buf, &len); > - ut_crc32_64_legacy_big_endian_hw(&crc, &buf, &len); > - } > - > - while (len >= 8) { > - ut_crc32_64_legacy_big_endian_hw(&crc, &buf, &len); > - } > - > - while (len > 0) { > - ut_crc32_8_hw(&crc, &buf, &len); > - } > - > - return(~crc); > -} > #endif /* defined(__GNUC__) && defined(__x86_64__) */ > > /* CRC32 software implementation. */ > @@ -600,7 +515,7 @@ integers. > @param[in] len data length > @return CRC-32C (polynomial 0x11EDC6F41) */ > uint32_t > -ut_crc32_legacy_big_endian_sw( > +ut_crc32_legacy_big_endian( > const byte* buf, > ulint len) > { > @@ -654,7 +569,6 @@ ut_crc32_init() > { > ut_crc32_slice8_table_init(); > ut_crc32 = ut_crc32_sw; > - ut_crc32_legacy_big_endian = ut_crc32_legacy_big_endian_sw; > ut_crc32_implementation = "Using generic crc32 instructions"; > > #if defined(__GNUC__) && defined(__x86_64__) > @@ -687,7 +601,6 @@ ut_crc32_init() > > if (features_ecx & 1 << 20) { > ut_crc32 = ut_crc32_hw; > - ut_crc32_legacy_big_endian = ut_crc32_legacy_big_endian_hw; > ut_crc32_implementation = "Using SSE2 crc32 instructions"; > } > > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits -- Marko Mäkelä, Lead Developer InnoDB MariaDB Corporation DON’T MISS M|18 MariaDB User Conference February 26 - 27, 2018 New York City https://m18.mariadb.com/

1 0

Re: [Maria-developers] [Commits] 14bd406: Less code to depend on ut_crc32_init()
by Marko Mäkelä 23 Nov '17

23 Nov '17

Thanks, this looks OK to me. I guess the function ut_crc32_init() will be made optional separately. On Thu, Nov 23, 2017 at 1:22 PM, Sergey Vojtovich <svoj(a)mariadb.org> wrote: > revision-id: 14bd406970c9bb18c744a452359aa4505f325b2d > (mariadb-10.3.2-67-g14bd406) > parent(s): f28af027a0439d760c6d26eb67a932e97eb665d7 > committer: Sergey Vojtovich > timestamp: 2017-11-23 15:22:10 +0400 > message: > > Less code to depend on ut_crc32_init() > > --- > storage/innobase/include/ut0crc32.h | 1 + > storage/innobase/ut/ut0crc32.cc | 20 +++++++------------- > 2 files changed, 8 insertions(+), 13 deletions(-) > > diff --git a/storage/innobase/include/ut0crc32.h > b/storage/innobase/include/ut0crc32.h > index 527a3e81..32ad066 100644 > --- a/storage/innobase/include/ut0crc32.h > +++ b/storage/innobase/include/ut0crc32.h > @@ -51,6 +51,7 @@ extern ut_crc32_func_t ut_crc32; > when converting byte strings to integers internally. */ > extern uint32_t ut_crc32_legacy_big_endian(const byte* buf, ulint len); > > +/** Text description of CRC32 implementation */ > extern const char* ut_crc32_implementation; > > #endif /* ut0crc32_h */ > diff --git a/storage/innobase/ut/ut0crc32.cc b/storage/innobase/ut/ > ut0crc32.cc > index 36c52b7..48f6b82 100644 > --- a/storage/innobase/ut/ut0crc32.cc > +++ b/storage/innobase/ut/ut0crc32.cc > @@ -86,12 +86,6 @@ mysys/my_perf.c, contributed by Facebook under the > following license. > #include "univ.i" > #include "ut0crc32.h" > > -/** Pointer to CRC32 calculation function. */ > -ut_crc32_func_t ut_crc32; > - > -/** Text description of CRC32 implementation */ > -const char* ut_crc32_implementation; > - > /** Swap the byte order of an 8 byte integer. > @param[in] i 8-byte integer > @return 8-byte integer */ > @@ -125,6 +119,13 @@ ut_crc32_power8( > { > return crc32c_vpmsum(0, buf, len); > } > + > +ut_crc32_func_t ut_crc32 = ut_crc32_power8; > +const char* ut_crc32_implementation = "Using POWER8 crc32 > instructions"; > +#else > +uint32_t ut_crc32_sw(const byte* buf, ulint len); > +ut_crc32_func_t ut_crc32 = ut_crc32_sw; > +const char* ut_crc32_implementation = "Using generic crc32 > instructions"; > #endif > > #if defined(__GNUC__) && defined(__x86_64__) > @@ -568,8 +569,6 @@ ut_crc32_init() > /*===========*/ > { > ut_crc32_slice8_table_init(); > - ut_crc32 = ut_crc32_sw; > - ut_crc32_implementation = "Using generic crc32 instructions"; > > #if defined(__GNUC__) && defined(__x86_64__) > uint32_t vend[3]; > @@ -603,10 +602,5 @@ ut_crc32_init() > ut_crc32 = ut_crc32_hw; > ut_crc32_implementation = "Using SSE2 crc32 instructions"; > } > - > -#elif defined(HAVE_CRC32_VPMSUM) > - ut_crc32 = ut_crc32_power8; > - ut_crc32_implementation = "Using POWER8 crc32 instructions"; > #endif > - > } > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits -- Marko Mäkelä, Lead Developer InnoDB MariaDB Corporation DON’T MISS M|18 MariaDB User Conference February 26 - 27, 2018 New York City https://m18.mariadb.com/

1 0

[Maria-developers] IB: trx_t:: start_time and start_time_micro
by Aleksey Midenkov 21 Nov '17

21 Nov '17

Hello! Different semantics of these 2 members doesn't look good: time_t start_time; /*!< time the state last time became TRX_STATE_ACTIVE */ ib_uint64_t start_time_micro; /*!< start time of transaction in microseconds */ Either `start_time_micro` should be drawn to the base of `start_time` or it should be explicitly commented that it has nothing to do with `start_time`. I.e. there is nothing wrong on algorithmic level, but such data members may (and certainly would) lead developers to misuse of `start_time_micro`. -- All the best, Aleksey Midenkov @midenok

2 2

[Maria-developers] Please review MDEV-11292 Item_func_sp::fix_length_and_dec() does not set collation derivation properly
by Alexander Barkov 20 Nov '17

20 Nov '17

Hello Alexey, Please review a patch for MDEV-11292 (for 10.3). Thanks.

2 2

[Maria-developers] MariaDB GUI: BSL 1.1 - Debate
by Juan Telleria 19 Nov '17

19 Nov '17

Dear MariaDb Developers, I am writing because I would like to open a debate whether if MariaDB, now that has gained investment from Microsoft, Alibaba, and the European Union, shall create its own SQL Graphical User Interface, as good as (or better than) MySQL Workbench. I agree that MariaDB includes by default HeidiSQL in its Windows builds, but in my opinion, if MariaDB really wants to look Oracle's MySQL face to face, HeidiSQL is not nearly as good as MySQL Workbench. If this wants to be done: 1st) The brand new GUI shall have a Business Source Licence v1.1, which only companies which invest in MariaDB would be able to use. 2nd) In 3 years now, MariaDB would be better positioned and have a fully Open Source GUI which would allow MariaDB to look face to face to Oracle. 3rd) And in 4/5 years now, MariaDB Corporation shall be brave enough to to continue Developing this GUI as a truly open source product, without the BSL, and adopting a purely GPLv2 with incremental improvements, distributing it through the MariaDB Foundation Webpage, as individuals or other companies apart from MariaDB Corporation, will not support the product if it is not totally Open Source. So BSL v1.1 might prove useful to launch the project, but with time, it shall have a GPLv2 for gaining investment from third companies. ¿What do you thing on the topic? Thank you all, Juan Telleria

1 0

[Maria-developers] Please review MDEV-13788 Server crash when issuing bad SQL partition syntax
by Alexander Barkov 16 Nov '17

16 Nov '17

Hello Sergei, Can you please review a patch for MDEV-13788, for 5.5? Thanks!

2 3

Re: [Maria-developers] MDEV-10173.
by Sergei Golubchik 15 Nov '17

15 Nov '17

Hi, Alexey! On Nov 14, Alexey Botchkov wrote: > Hi, Serg. > > I'd like your opinion about this issue. > Georg complains about weird column metadata > https://jira.mariadb.org/browse/MDEV-10173 > > Personally i see slightly different result, but basically same thing. > -------------------------------- > MariaDB [(none)]> select from_unixtime("0"); > Field 1: `from_unixtime("0")` > Catalog: `def` > Database: `` > Table: `` > Org_table: `` > Type: DATETIME > Collation: binary (63) > Length: 26 > Max_length: 19 > Decimals: 39 > Flags: BINARY Right, I get used to 31 being NOT_FIXED_DEC. But recently Monty changed it to 39. > +---------------------+ > | from_unixtime("0") | > +---------------------+ > | 1970-01-01 04:00:00 | > +---------------------+ > 1 row in set (0.00 sec) > -------------------------------- > > From what i see it is not a bug. The 'Decimals: 39' is not a real > precision here, but just a hint to be flexible converting the data to > the string. The 'Length: 26' takes into account the possible > 'second_part' of 6 digits. Agree. > Georg said on this: "Well, the client "trusts" the metadata. If there > is decimal 31, it appends 31 decimal places and returned truncation > error the metadata (MYSQL_FIELD) describes the data which are sent > from server to client. If there are no decimal places, it should be > zero. " Yes, the cient trusts the metadata, but if decimals is NOT_FIXED_DEC it means "unknown", not 31 (or 39). If the number of decimals for a timestamp is unknown, the max length is 26: "YYYY-MM-DD hh:mm:ss.uuuuuu" > As an improvement i can see using '7' instead of '39' as an > 'NOT_FIXED_DEC' marker for the Item_temporal_func. Why? One wouldn't be able simply to compare with NOT_FIXED_DEC, it'll be type dependent. > Or we can just document that '39' value so clients interpret it right. Isn't it documented? > Serg, maybe you can suggest something? Close as "Not a bug" :) Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] [Commits] 730a22c: Fixed bug mdev-13453 Executing a query via CTE requires more permissions
by Oleksandr Byelkin 14 Nov '17

14 Nov '17

Am 14.11.2017 um 01:06 schrieb IgorBabaev: > revision-id: 730a22c1ce1010e853e7a3e807d1d07409ec4dfc (mariadb-10.2.10-28-g730a22c) > parent(s): 1e2d4f677e08294691a7d218acb3b9f78727ae18 > author: Igor Babaev > committer: Igor Babaev > timestamp: 2017-11-13 16:06:04 -0800 > message: > > Fixed bug mdev-13453 Executing a query via CTE requires more permissions > than the query itself > > ACL checks were not properly supported for tables used in CTE > specifications. This patch fixes the problem. > > --- > mysql-test/r/cte_nonrecursive.result | 58 ++++++++++++++++++++++++++++++++++++ > mysql-test/t/cte_nonrecursive.test | 51 +++++++++++++++++++++++++++++++ > sql/sql_acl.cc | 4 +++ > sql/sql_cte.cc | 3 +- > sql/sql_parse.cc | 4 +++ > 5 files changed, 119 insertions(+), 1 deletion(-) > > diff --git a/mysql-test/r/cte_nonrecursive.result b/mysql-test/r/cte_nonrecursive.result > index ebe1aae..92f9151 100644 > --- a/mysql-test/r/cte_nonrecursive.result > +++ b/mysql-test/r/cte_nonrecursive.result > @@ -1147,3 +1147,61 @@ SELECT * FROM cte_test; > a > 1 > DROP VIEW cte_test; > +# > +# MDEV-13453: > +# [skip] > --- a/mysql-test/t/cte_nonrecursive.test > +++ b/mysql-test/t/cte_nonrecursive.test > @@ -790,3 +790,54 @@ SHOW CREATE VIEW cte_test; > SELECT * FROM cte_test; > > DROP VIEW cte_test; > + > +--echo # > +--echo # MDEV-13453: privileges checking for CTE > +--echo # > + This is for sure do not match results above, so please fix it and make sure that full test suite passed. [skip] > --- a/sql/sql_acl.cc > +++ b/sql/sql_acl.cc > @@ -7557,6 +7557,10 @@ bool check_grant(THD *thd, ulong want_access, TABLE_LIST *tables, > tl->correspondent_table ? tl->correspondent_table : tl; > sctx= t_ref->security_ctx ? t_ref->security_ctx : thd->security_ctx; > > + if (tl->with || > + (tl->with= tl->select_lex->find_table_def_in_with_clauses(tl))) > + continue; > + > const ACL_internal_table_access *access= > get_cached_table_access(&t_ref->grant.m_internal, > t_ref->get_db_name(), > diff --git a/sql/sql_cte.cc b/sql/sql_cte.cc > index 6fe08e3..e1bd455 100644 > --- a/sql/sql_cte.cc > +++ b/sql/sql_cte.cc > @@ -823,9 +823,10 @@ st_select_lex_unit *With_element::clone_parsed_spec(THD *thd, > tbl; > tbl= tbl->next_global) > { > - tbl->grant.privilege= with_table->grant.privilege; > spec_tables_tail= tbl; > } > + if (check_table_access(thd, SELECT_ACL, spec_tables, FALSE, UINT_MAX, FALSE)) > + goto err; > if (spec_tables) > { > if (with_table->next_global) > diff --git a/sql/sql_parse.cc b/sql/sql_parse.cc > index bf5144b..39a4da9 100644 > --- a/sql/sql_parse.cc > +++ b/sql/sql_parse.cc > @@ -3443,6 +3443,10 @@ mysql_execute_command(THD *thd) > ulong privileges_requested= lex->exchange ? SELECT_ACL | FILE_ACL : > SELECT_ACL; > > + res= check_dependencies_in_with_clauses(thd->lex->with_clauses_list); > + if (res) > + break; Above works only for SELECT, do we support CTE in subselects which can be put everywhere? > + > if (all_tables) > res= check_table_access(thd, > privileges_requested, > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits

1 0

Re: [Maria-developers] Handle failures from malloc
by Sergey Petrunia 14 Nov '17

14 Nov '17

Hi Monty, Please find my comments below. Anything not commented on seems to be ok to me. > commit 7d9c24f6790c66d2f457837661852bf5e870b605 > Author: Michael Widenius <monty(a)mariadb.org> > Date: Tue Nov 14 07:47:58 2017 +0200 > > Handle failures from malloc > > Most "new" failures fixed in the following files: > - sql_select.cc > - item.cc > - opt_subselect.cc > > diff --git a/sql/item.cc b/sql/item.cc > index 2285ae28041..baae2a9b6fb 100644 > --- a/sql/item.cc > +++ b/sql/item.cc > @@ -1261,7 +1261,7 @@ Item *Item::safe_charset_converter(THD *thd, CHARSET_INFO *tocs) > if (!needs_charset_converter(tocs)) > return this; > Item_func_conv_charset *conv= new (thd->mem_root) Item_func_conv_charset(thd, this, tocs, 1); > - return conv->safe ? conv : NULL; > + return conv && conv->safe ? conv : NULL; > } > I am not fully convinced that returning NULL from this function is called everywhere. It is of course better to return NULL and hope for the best than to crash right away. > @@ -3296,6 +3301,8 @@ void Item_field::fix_after_pullout(st_select_lex *new_parent, Item **ref, > } > > Name_resolution_context *ctx= new Name_resolution_context(); > + if (ctx) > + return; // Fatal error set > if (context->select_lex == new_parent) > { > /* I assume this is a typo it should be "if (!ctx)" > diff --git a/sql/sql_select.cc b/sql/sql_select.cc > index abbf2616537..7e42890143b 100644 > --- a/sql/sql_select.cc > +++ b/sql/sql_select.cc > @@ -713,7 +713,7 @@ JOIN::prepare(TABLE_LIST *tables_init, > union_part= unit_arg->is_unit_op(); > > if (select_lex->handle_derived(thd->lex, DT_PREPARE)) > - DBUG_RETURN(1); > + DBUG_RETURN(-1); > > thd->lex->current_select->context_analysis_place= NO_MATTER; > thd->lex->current_select->is_item_list_lookup= 1; I assume this is just for the sake of consistency with other DBUG_RETURN statements in this function? > @@ -14422,7 +14446,7 @@ static COND* substitute_for_best_equal_field(THD *thd, JOIN_TAB *context_tab, > This works OK with PS/SP re-execution as changes are made to > the arguments of AND/OR items only > */ > - if (new_item != item) > + if (new_item && new_item != item) > li.replace(new_item); > } new_item was returned from a substitute_for_best_equal_field() call. That one doesn't ever return NULL. It will return without substitution if it encounters an error. So this change is not needed. > @@ -25044,8 +25103,11 @@ int JOIN::save_explain_data_intern(Explain_query *output, > > if (message) > { > - explain= new (output->mem_root) Explain_select(output->mem_root, > - thd->lex->analyze_stmt); > + if (!(explain= new (output->mem_root) > + Explain_select(output->mem_root, > + thd->lex->analyze_stmt))) > + DBUG_RETURN(1); > + > join->select_lex->set_explain_type(true); > > explain->select_id= join->select_lex->select_number; The return value of this function is not checked. I assume the above statement is there so that we dont try to continue to execute the function if we've got an OOM error? In this case, probably JOIN::save_explain_data_intern() should also have a similar check for its tab->save_explain_data(eta, used_tables, distinct_arg, first_top_tab); call? BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] STRICT mode and Cast
by jerome brauge 14 Nov '17

14 Nov '17

Hello Alexander, To have a behavior the nearest possible to Oracle, I use STRICT_TRANS_TABLES sql_mode. But then I have a problem with cast to varchar that failed with "truncated incorrect value" . Ex: set sql_mode='ORACLE,STRICT_TRANS_TABLES'; delimiter / CREATE or replace procedure p3(b1 integer) AS strres VARCHAR(4); BEGIN strres:=cast('123456' as char(4)); END / call p3(-1) / -- Failed with : ERROR 1292 (22007): Truncated incorrect CHAR(4) value: '123456' But select cast('11111' as varchar(2)) from dual; just issue a warning, not an error. On Oracle, Sybase,SQLServer and DB2, cast a string to a shorter string never issue warnings nor error. What do you think about ? Regards, Jérôme.

2 4