Martin MC Brown wrote: > >> >> >> Looking there, it appears one difference is no direct access to the >> THD structure. In the past, I'd found many of the things I wanted to >> do needed to follow this around MySQL. Is the intent with the >> connectionid and query to be able to follow this around? >> Maybe I'm misreading this though. > > > No, you are not misreading. > > The connectionid we expose at different levels is the same as the > MySQL process ID (as shown within MySQL with SHOW PROCESSLIST), and we > also provide the dbname, user, and host at specific levels where > appropriate. > > The most common reason for needing access to the THD structure is > either to get a common reference number number (the thread process ID > as used in MySQL) and/or detail like the database and user that > submitted the query. Exposing the THD is messy, consumes a lot of > resource (comparatively) when tracing and has the unfortunate effect > of exposing a lot of information that most people either don't need or > shouldn't need to have access to.
Actually, I think the processid/connectionid is what I'd most often needed, and having it in an argument makes it even simpler than having to deal with defining the THD struct. So far, I think I like the change, but just wanted to be sure that the connectionid/process ID was what I thought it was. If I run into something else I need, I'll let you know. Again, thanks for thinking this through and getting it in! We should document this for Web Stack 1.5. - Matt
