← Back to team overview

maria-developers team mailing list archive

Re: c91ec05e01b: MDEV-20865 Store foreign key info in TABLE_SHARE

 

Hi, Aleksey!

On Dec 18, Aleksey Midenkov wrote:
> Sergei,
> 
> On Wed, Dec 18, 2019 at 1:11 PM Sergei Golubchik <serg@xxxxxxxxxxx> 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@xxxxxxxxxxx


Follow ups

References