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
On Thu, 6 Jul 2023 at 20:06, Sergei Golubchik <serg@mariadb.org> wrote: 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 -- Yours truly, Nikita Malyavin