LEX_CSTRING defines a string by a pointer and a length.
You shouldn't use functions that stop at first '\0'.
In some contexts (for table names, for example) it might be ok, but here
you create a generic LEX_CSTRING concatenation, let's not implicitly
assume that there are not zero bytes inside.
Ouch! Right, there are more encodings than I can encounter. In fact, i don't even know if 0 can be met in any sort of utf.
> > > @@ -9869,26 +9869,21 @@ bool online_alter_check_autoinc(const THD *thd, const Alter_info *alter_info,
> > > */
> > > for (uint k= 0; k < table->s->keys; k++)
> > > {
> > > - const KEY &key= table->s->key_info[k];
> > > + const KEY &key= table->key_info[k];
> >
> > This is generally incorrect. User specified keys are in
> > table->s->key_info[] Keys in table->key_info[] can be modified to
> > match what indexes are actually created, in particular, for long
> > uniques table->key_info[] differs from table->s->key_info[]
>
> Maybe, but hopefully, long unique is not HA_NOSAME.
> I need table->key[i].key_part[j].field to compare with copy_field.field.
can you compare indices instead?
I can, but why do you suppose table->s->key_info is the correct one?
Rows_log_event::find_key enumerates table->key-info to find a unique key.
It only checks m_table->s->keys_in_use.is_set(i). Though it seems unrelated, I suppose I could have to check it as well, but I couldn't find what drives its values apart from ALTER TABLE DISABLE KEYS, which skips unique keys. What do you think?
Regards,
Sergei
VP of MariaDB Server Engineering
and security@mariadb.org