>>>>> "Timothy" == Timothy P Clark <Timothy> writes:
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
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
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
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
This means that if your primary keys works differently from normal
keys, you need to detect this case in the handler.