First flesh wound in create_tmp_table()

If you have needed a good reason to drink heavily and forget, may I suggest taking a look at create_tmp_table() and those who call it. It’s probably one of the best illustrations of rot and awful, incomprehensible APIs in the server (Drizzle inherited it from MySQL).

In the normal paths for CREATE TABLE, you construct a data structure describing the table you want, create it and then open it. Opening a table gives you objects you can use to access it.

create_tmp_table() instead constructs these objects directly and then does some direct calls into specific storage engines (ever wondered why you can’t use your own storage engine for temporary tables created during query execution? this is why). So instead of having one place to construct TableShare and Table, we have create_tmp_table() doing its own thing.

I struck a blow against it today. Using the standard interfaces to create and open a table, I got the temporary tables created for INFORMATION_SCHEMA tables to use them and not create_tmp_table().

When I finish converting the other 3 or 4 places that use create_tmp_table, I’ll be able to cut out at least 700 odd lines of code, cut out the horrible special case in the HEAP engine for “create table on open() even if create() was never called” and have an easy time making the transition to fully using the table proto as the specification for table structure.

2 thoughts on “First flesh wound in create_tmp_table()

  1. each unhygienic lines of code can be hiding place for set of bugs.
    and future problems.
    You are doing a great job. A mass sanitation.
    i believe in 80-20 rule. 20% of code creates 80% problems

    consolidation of functionality got another point from quality assurance.
    same code will be reused again and again (repeated tests)

    and less number of function points means less number of bugs and issues. happy life :)

    Thank you,

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.