Hi, Kristian, On Sep 12, Kristian Nielsen wrote:

diff --git a/sql/sys_vars.cc b/sql/sys_vars.cc index e25d293bbb7..18d08996aa8 100644 --- a/sql/sys_vars.cc +++ b/sql/sys_vars.cc @@ -3863,12 +3863,13 @@ static const char *old_mode_names[]= "IGNORE_INDEX_ONLY_FOR_JOIN", // deprecated since 11.3 "COMPAT_5_1_CHECKSUM", // deprecated since 11.3 "LOCK_ALTER_TABLE_COPY", // deprecated since 11.3 + "COMPAT_DISCOURAGED", 0 };

void old_mode_deprecated_warnings(THD *thd, ulonglong v) { - v &= ~OLD_MODE_DEFAULT_VALUE; + v &= ~(OLD_MODE_DEFAULT_VALUE | OLD_MODE_COMPAT_DISCOURAGED);

No, this is wrong. old-mode *by definition* is something that is a temporary workaround for something new, old-mode values are by design deprecated from the day one. So, OLD_MODE_COMPAT_DISCOURAGED shouldn't be on the line above, and thus it'll itself be deprecated and will cause a deprecation warning. Which is rather silly, as I wrote in a previous email, and that's why an old-mode is not a good solution for turning deprecated warnings away.

for (uint i=0; old_mode_names[i]; i++) if ((1ULL<<i) & v) { diff --git a/sql/item_strfunc.cc b/sql/item_strfunc.cc index 4b96271c331..339430a2794 100644 --- a/sql/item_strfunc.cc +++ b/sql/item_strfunc.cc @@ -2720,7 +2720,16 @@ bool Item_func_encode::seed() hash_password(rand_nr, key->ptr(), key->length()); sql_crypt.init(rand_nr);

- warn_deprecated<1103>(current_thd, func_name_cstring().str); + if (!(current_thd->variables.old_behavior & OLD_MODE_COMPAT_DISCOURAGED)) + { + /* + This function should not be removed despite the deprecation warning. + That would cause problems for users who can then no longer access + columns in their database that might have been inserted as + ENCODE(str,pass_str). + */ + warn_deprecated<1103>(current_thd, func_name_cstring().str); + }

No, this is exactly what I wanted to prevent by adding a warn_deprecated<>() wrapper. If something is giving a warning "... is deprecated and will be removed" - it *has to be removed*. We don't want to lie to users to simply scare them. If we promise to do something, we should do it. If we aren't going to remove ENCODE/DECODE functions, we shouldn't deprecate them at all. Which is the result I'm leaning to right now.

return FALSE; }

Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org