Hi!
>>>>> "Timothy" == Timothy P Clark <Timothy> writes:
<cut>
>> If there is no primary keys in the table, MySQL will when opening the
>> table for the first time internally promote any unique key without
>> NULL fields to a primary key and thus set table->s->primary to point
>> to this.
>>
>> This means that if your primary keys works differently from normal
>> keys, you need to detect this case in the handler.
Timothy> This is exactly the case that I am encountering. So, if I understand
Timothy> correctly, in handler::add_index() I'll need to check for an existing
Timothy> primary key. If there is none existing, then as I loop through the indices
Timothy> that are being added, if there is no new key with the name "PRIMARY", when
Timothy> I encounter the first unique non-null index, I need to promote this to a
Timothy> primary key in my internal definition.
Should work.
Timothy> Is this correct? And is this solution "future-proof"? In other words, the
Timothy> internal promotion done by open_binary_frm() does not appear to be
Timothy> documented externally. Is it possible that this behavior may be modified in
Timothy> future releases, thereby breaking our handler?
This is not planned to change (as far as I know).
MySQL uses info->s->primary_key to be able to refer to a row in other
context, like row based replication.
Regards,
Monty
