We really shouldn't deprecate without a good reason. It breaks things for users.
Even a warning sounds harmful. How does it help the users? A large number of MariaDB users/DBA are using applications that they do not control or modify themselves.

Explaining the properties of AES_ENCRYPT vs. ENCODE is for the documentation. There are other use cases than "cannot be easily cracked". rot13 is "easily cracked", but is still used.

Unfortunately, users don't read documentation as much as I'd preferred them to.
And when the user base is growing exponentially a larger number of new users start using MariaDB, pick the function that looks like it's doing about what they need, and use it. Ideally it should be very difficult or impossible to make a wrong choice. But as we cannot do that, we should at least warn them when they choose badly.

Good that you agree not to deprecate/remove the functions and break backwards compatibility.

But server warnings is not a marketing platforms for what we want our users to do or not do in their applications. Either the warnings will turn up where they will generate noise and extra work for existing users/applications, which we should avoid. Or they will be invisible and thus pointless anyway.

The functions are called "encode" and "decode", there's no reason users would expect them to have anything to do with encryption, if it wasn't that the documentation https://mariadb.com/kb/en/encode/ uses the word "encrypt"!

The documentation is quite bad, it doesn't even describe the algorithm used to encode/decode. Let's change this issue to be a documentation bug, to explain the encoding algorithm used, to not say they do encryption (if they don't), and maybe say that they are there for backwards compatible with existing applications.

They do encryption. With the some home grown algorithm a non-cryptographer could have invented. It's a combination of substitution and XOR

Review mailing list thread:

https://lists.mariadb.org/hyperkitty/list/developers@lists.mariadb.org/thread/Y3K5F6IHH5R4M3TW6NRO5TLF5234SYFE/

https://dev.mysql.com/worklog/task/?id=6984 - I am adding this just for completeness. It is not an argument pro/con, but one more reason why we looked at deprecating the functions.

From my point of deprecation has the goal to make users aware that they should not use it anymore for new applications and should plan a change of their application. In some cases the removal can be something happening soon after the deprecation, in other cases like this removing the function needs to be many years after deprecating it. And only in a major version (major in the sense of a change of the first number).

My view about changing the documentation. Whatever we do in the KB to make the users aware of the fact, that DECODE/ENCODE are not encryption functions, there are so many documentations for MySQL and MariaDB out there where the functions are called encryption functions. We still need to make this clear in the KB, but we need to be aware that this change itself we not stop the functions to be used with a wrong expectation by even new users and for new applications.

About the argument that we get too many deprecation warnings (and I know the risk that my suggestion might trigger new discussion), a compromise could be to have a deprecation warning only for ENCODE(), which at the end is the function where a wrong expectation is out there to be an encryption. ENCODE() will for sure used less by applications compared to DECODE(). The deprecation warning could still mention both functions.

JM2C, as I created the ticket