Sergei Golubchik <serg@stripped> wrote on 07/16/2009 04:53:44 AM:
> Hi, Timothy!
> On Jul 08, Timothy P Clark wrote:
> > This one has been plaguing me for a while, and I'm hoping someone can
> > help...
> > What I'm trying to do in my storage engine is determine when creating
> > index whether it is a prefix key [e.g. CREATE TABLE t1 (c char(10),
> > index(c(5)))]. I do this for a given key by comparing
> > key.key_part[x].length to
> > key.key_part[x].field->table->field[key.key_part[x].fieldnr-1]
> do you mean that
> key.key_part[x].field !=
Yes, when prefix keys are involved. That is why I cannot simply compare
if (key.key_part[x].length == key.key_part[x].field->max_display_length())
> > If those values are different, I assume that the key is a prefix key.
> > I want to be able to use the same code both for indexes created along
> > with the table (through handler::create()) and by online ALTER
> > (through handler::add_index()). The problem is that the key_part
> > structure appears to be constructed slightly differently depending on
> > whether it is coming through handler::create() or through
> > handler::add_index(). Significantly, fieldnr appears to be one-based
> > through create() and zero-based through add_index(). Obviously this
> > difference complicates the construction of a general test for prefix
> > keys.
> > In other words, for
> > CREATE TABLE t1 (c char(10), index(c(5)))
> > in handler::create(), table_arg->key_info.key_part.fieldnr = 1.
> > But for
> > CREATE TABLE t1 (c char(10));
> > ALTER TABLE t1 ADD INDEX(c(5));
> > in handler::add_index(), key->key_info.key_part.fieldnr = 0.
> > First, is my method for identifying prefix keys otherwise correct? I
> > haven't found a more straightforward way, but maybe there's something
> > simpler?
> > Second, is there a reason that fieldnr is different between these two
> > functions, or is that just an oversight that needs to coded around?
> I don't see a reason fot this discrepancy.
> Looks like an oversight. Feel free to report it as a bug.
Submitted as Bug#46228
> Regards / Mit vielen Grüßen,
> __ ___ ___ ____ __
> / |/ /_ __/ __/ __ \/ / Sergei Golubchik <serg@stripped>
> / /|_/ / // /\ \/ /_/ / /__ Principal Software Engineer/Server
> /_/ /_/\_, /___/\___\_\___/ Sun Microsystems GmbH, HRB München 161028
> <___/ Sonnenallee 1, 85551 Kirchheim-Heimstetten
> Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
> Vorsitzender des Aufsichtsrates: Martin Häring