Generally: Don't try to detect injections, avoid them. Restrict every input to a set of save characters, abort whenever you see invalid input. Don't try to repair invalid input, doing so often opens another way for injections.

Even more generally for any DBI application: Let DBI handle the quoting for you. Use prepared statements with placeholders, DBI will take care of proper quoting, should the database wire protocol require any quoting. Use the quote_identifier() method to quote any identifier (column names, table names). DBI might not contain code to handle your specific database requirements, but the DBD you are using sure does.

Specifically for your problem: Don't allow free text input. You know (or can find out) what types are supported by your database. Use something like a dropdown list or radio buttons to let the user select one of the available types. Some types need additional data, like VARCHAR or NUMBER. You know when to ask for that, it depends on the selected type. Use one or two additional input fields, and accept only numbers there. NULL / NOT NULL: Use a checkbox. The same for the primary key constraint. Unique constraints need a name and a list of existing column names. Also no problem, ask for a name and offer a multi-select for the columns. The same rules apply for other constructs found in CREATE TABLE statement, like foreign keys. Finally, assemble all of the information bits into a big CREATE TABLE statement. Bonus points for detecting missing primary keys.

You did not say anything about your environment, so I assumed web or GUI. In text mode, you have to ask a lot more questions than you do now, but the principle stays the same: Ask for one piece of information at a time, and validate the input.

Alexander