Hi, Nikita,
On Jul 06, Nikita Malyavin wrote:
> > > > @@ -9869,26 +9869,21 @@ bool online_alter_check_autoinc
> > > > > */
> > > > > 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?
Because that's how the code works. TABLE_SHARE stores index definitions
as specified by the user, as shown in SHOW CREATE TABLE and I_S tables.
And why would I need them as specified by the user?? All I need is to make sure
that we have a unique constraint, which is unchanged. It will identify the row.
We are replicating every field the user might be unaware of (excluding pure virtuals,
which are deducible), so we don't care of the formal user-defined specification.
TABLE stores index definitions as seen by the engine.
Which is often (almost always) the same thing. But only almost.
i didn't know about it when i wrote it first. Disregarding that, I think table->key_info
is a correct thing to use here, as it reflects the data that is really stored and can be
used for the row identification