Yes, Sergei, you are right, it works fine!

Additionally, I see now that I implement something very similar to what Sachin does -- i.e., cloning handler.

I think that we can share one handler among all similar stuff, when we need to make cascade index searches. But some refactoring is required -- TABLE::clone_handler_for_update is not actually "for update" but rather for read, and I think it's better to store the handler in parent handler (as well as clone function), and to call it smth like `internal_handler` (I call it now check_overlaps_handler, and Sachin calls it update_handler).

Sergei, Sachin, agree?

On Tue, 17 Dec 2019 at 03:50, Sergei Golubchik <serg@mariadb.org> wrote:

Hi, Nikita!

On Dec 17, Nikita Malyavin wrote:
> It is used in innodb's implementation of handler::position, to copy the key
> from the record buffer, which is also used to be record[0]

Okay.

It seems that position() was always called with record[0] as an
argument.

But check_duplicate_long_entry_key() uses store_record()/restore_record()
to call position(record[0]). Please see if you can remove them now.

> On Tue, 17 Dec 2019 at 01:20, Sergei Golubchik <serg@mariadb.org> wrote:
> > Hi, Nikita!
> > On Dec 06, Nikita Malyavin wrote:
> > > Hi Sergei!
> > >
> > > I traced out the problem I faced with refs comparison -- It's in
> > > key_copy implementation, which uses field->get_key_image, which in
> > > turn copied data to the buffer passed, but from `field->ptr`. The
> > > latter is important -- it means, current key_copy implementation
> > > always copies data from table->record[0].
> >
> > I see. It looks like so far all usages of key_copy() used record[0]
> > indeed.
> >
> > But as far as I can see, you're also using key_copy() with
> > record[0], so why would you need that fix?
> >
Regards,
Sergei
VP of MariaDB Server Engineering
and security@mariadb.org