Hi!
>>>>> "Timothy" == Timothy P Clark <Timothy> writes:
Timothy> Hi,
Timothy> The storage engine that I am working on is required to treat primary keys
Timothy> differently than other indexes. As well, we would like our SE to be able to
Timothy> support online adding/dropping of indexes. The problem is that I'm
Timothy> uncertain how to reliably identify whether a key that the storage engine is
Timothy> given is actually a primary key. There appear to be two methods for
Timothy> determing whether a key is the primary key: using
> table->s->primary_key,
Timothy> and using the name of the key, which appears to always be "PRIMARY" for the
Timothy> primary key.
Timothy> I assumed that the first option (table->s->primary_key) would be the
> most
Timothy> reliable method.
Yes, this is the correct way to do this.
Timothy> However, when a key is added to an existing table, this
Timothy> information is not updated before handler::add_index is called.
For add index you have to reply on the name as at this point the new
table definition is not yet active.
Timothy> Consequently, it seems that I am required to rely on the name of the key (
Timothy> == "PRIMARY") to determine whether it is the primary key.
Timothy> Can I always rely on the name of the key? If not, what can I use in
Timothy> add_index to know whether the key should be the primary key?
For primary keys, the name will always work. There is however one
small problem:
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.
Regards,
Monty
