Hi, Aleksey! On Dec 18, Aleksey Midenkov wrote:
Sergei,
On Wed, Dec 18, 2019 at 1:11 PM Sergei Golubchik <serg@mariadb.org> wrote:
Hi, Aleksey!
On Dec 18, Aleksey Midenkov wrote:
On Wed, Dec 4, 2019 at 10:10 PM Sergei Golubchik wrote:
But it's better to be from the other side:
bool Lex_cstring::strdup(MEM_ROOT *mem_root, const Lex_cstring &src) { // allocate and deep-copy from src to this }
I'd really like to use such utility methods instead of C variants like thd_make_lex_string(). ... We better go away from this C service layer of thd_*() functions between server and plugins and use class methods instead.
Why is it better? Isn't it just the syntax sugar?
Having local class interfaces is easier to maintain. Additional API layer is development costs overhead.
That's neglectable, thd_make_lex_string() needs next to no maintainance.
It is good for version compatibility control, but we don't have third-party plugins, do we?
I don't know. There definitely were third-party storage engines, third-party fulltext parsers, etc. In fact, I'm sure there are third-party plugins that I know nothing about (besides the fact that they exist).
And we don't strictly use API to get server services into plugin, AFAIK.
This is automatic, any plugin that uses thd_make_lex_string() uses the "thd_alloc" service.
The only effect I can think of - pure C plugins won't be able to use thd_make_lex_string() if you replace it with a C++ method.
Do we have such plugins and do we need them to stay pure C?
No, not for thd_make_lex_string(). Of all the plugins I know of, only storage engines use it at the moment and they all are C++. Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org