I got rid of unireg.cc way back in 2009 as I rewrote all the FRM related code inside Drizzle to instead use a nice protobuf based structure. If you’re wondering what was there, I just quote this part of pack_screens() from unireg.cc in MySQL 5.6:
start_row=4; end_row=22; cols=80; fields_on_screen=end_row+1-start_row;
We have gradually pulled things out of unireg.h over the years too. But, let’s go back to ask the question “What is UNIREG?”. To answer that, I’m going to quote from something that was current back when MySQL 3.22 was the latest and greatest:
In 1979, he developed an in-house database tool called UNIREG for managing databases. Since 1979, UNIREG has been rewritten in several different languages and extended to handle big databases.
No doubt the definition of big has changed for most people since then. If we take what the MySQL 3.23 manual said:
Unireg is our tty interface builder, but it uses a low level connection to our ISAM (which is used by MySQL) and because of this it is very quick. It has existed since 1979 (on Unix in C since ~1986).
This is where the FRM file comes from, and likely where unireg.cc and unireg.h in MySQL Â originated from. Since we didn’t want to have the limitations of FRM files in Drizzle, and since all code that mentioned UNIREG was generally not modern, we’ve been gradually removing bits or refactoring it since.
So, what was in unireg.h to begin with? I peeked into the MySQl 5.6 unireg.h to remind myself:
- defines for libc5
- defines for the MySQL thing that isn’t gettext
- the PLUGINDIR define
- some macros for errors
- a bunch of SPECIAL_ prefixed defines for a bitfield which is a truly odd thing.
- store_record(), restore_record(), cmp_record(), empty_record() macros
- defines for flags to openfrm(), openprt() and openfrd() (the latter two not being present in MySQL)
- defines used in relation to INFORMATION_SCHEMA tables and triggers
- the BIN_LOG_HEADER_SIZE define
- the DEFAULT_KEY_CACHE_NAME define
Soo… really a whole bunch of stuff that should never have been put there in the first place as most of that has clearly come in after it was MySQL.
But I’m getting sidetracked, the main point was that I looked at what was remaining in unireg.h inside Drizzle and it was just one thing:Â Code to abort the server in certain odd situations (that we’d completely rewritten so had no relation to unireg). So, I renamed it.
Renaming a file is a pretty minor change, but that hides all the work leading up to that point so that now I can go and explain Drizzle internals while making one less reference to UNIREG.
Now to go and remove the last tiny bit of unireg_check…