SQLSTATE[42000]: Syntax error or access violation

I tweaked the install hook to make the table sized appropriately. With this patch, I can install the module and it creates the table.

Whoops, had the wrong path in the patch. Ignore #2 and use this one.

Thanks for the patch.
Although setting the max length to 125 can help, we are looking at a rather fundamental problem with MySQL indexes: https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html

MySQL has a index length of 767 bytes. An emoji character, for example, is 4 bytes. This makes the 767 index limit is reached when 191 four-byte characters are used. If we were to limit the index size, the ideal length would be 191. Ideally, we should be running an update script to go through the table, and truncate all fields that caused the index size to go over 191 characters (mb_strlen() > 191), and then alter the table indices to have an index of 191.

As mentioned in #4, this needs a hook_update_N() to resize the table for existing sites that use this module.

This also causes even simple tests to fail on DrupalCI. See #3225738: Add test case for settings form

If this module had only had tests, this would have been caught and fixed long ago.

Is there any downside to reducing the 'code' column from 255 to 191? Does anyone really need registration codes that big? Alternatively, is it really necessary to keep 'code' as a 'unique key' ? Does that really help any of the queries made by this module?

Regardless, for either change, a hook_update_N() will be needed to modify the schema of existing sites. The first option, reducing the column size, will also require changing data by truncating existing codes if they are too long. A warning should be given, as that might not be the correct thing to do in some cases and might result in non-unique codes. It sounds like it would be easier just to remove the index, provided that doesn't hurt performance.

Here are two patches.

The first (9a) changes the 'code' column to 191 characters. This patch doesn't include a hook_update_N(), but that's mandatory to have before this can be committed.

The second (9b) just removes the index.

Both patches include a copy of the functional test from #3225738: Add test case for settings form because that test currently fails because of this bug. If one or both patches cause the test to PASS, that's a good sign.

Here's a new version of 9b (the patch that solves this problem by removing the unique key) that also adds a hook_update_N() for the removal of the unique key from existing sites that are updating this module.

I am getting this:

Performing regcode_update_8101                                                  
Failed: SQLSTATE[42S02]: Base table or view not found: 1146 Table                [error]
'site.regcode' doesn't exist: SHOW INDEX FROM "regcode" WHERE
key_name = 'code'; Array()

I am getting this

When doing what?
The {regcode} table must always exist if you have this module installed.