maria-developers team mailing list archive
-
maria-developers team
-
Mailing list archive
-
Message #12044
Re: c91ec05e01b: MDEV-20865 Store foreign key info in TABLE_SHARE
Hi, Sergei!
On Fri, Dec 27, 2019 at 8:22 PM Sergei Golubchik <serg@xxxxxxxxxxx> wrote:
> Hi, Aleksey!
>
> On Dec 22, Aleksey Midenkov wrote:
> > > >
> > > > Particularly to this function I don't like its name, semantics and
> > > > signature.
> > >
> > > As far as the service is concerned, "don't like" is too weak an
> > > argument, changing a service comes with a compatibility cost.
> >
> > Of course, if there is compatibility issue. That's not the case for
> > our in-tree plugins, I guess?
>
> You cannot base your decision on the belief that all plugins are
> in-tree. This API was created open for third-party plugins to use.
> So, we have to assume that third party plugins exist
> (and they do exist, check github, sourceforce, and jira).
>
My concern is mostly about our plugins. Let the third-party plugins use
that API, but our plugins are not restricted to it?
>
> > > > Now, to the THD::make_clex_string() and THD::make_lex_string().
> > > > These methods should not be in THD at all. Its monolithic design
> > > > with million of different methods looks to me as a huge mess
> > > > accumulated across long time. There was no need to create proxies
> > > > when there would not be such a large class in the first place.
> > >
> > > They could be methods of a MEM_ROOT. One shouldn't need a complete
> > > THD to allocate memory from a memroot.
> >
> > I believe, that's not much better than THD method. THD, MEM_ROOT are
> > generic classes, they should know nothing about classes they provide
> > services for.
>
> okay
>
> Regards,
> Sergei
> VP of MariaDB Server Engineering
> and security@xxxxxxxxxxx
>
--
All the best,
Aleksey Midenkov
@midenok
Follow ups
References