List:Internals« Previous MessageNext Message »
From:Michael Widenius Date:March 5 2008 8:48pm
Subject:re: Reliably identifying primary keys
View as plain text  

>>>>> "Timothy" == Timothy P Clark <Timothy> writes:


>> 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.

Reliably identifying primary keysTimothy P Clark4 Mar
  • re: Reliably identifying primary keysMichael Widenius5 Mar
    • re: Reliably identifying primary keysTimothy P Clark5 Mar
      • re: Reliably identifying primary keysMichael Widenius5 Mar
  • Re: Reliably identifying primary keysMartin Skold10 Mar