unique_table_name is imported twice

I would reorder the operands, but honestly I'm being picky here.

I sort-of deliberately chose this order, because validate is almost always true (previously validate=true) and the first condition is almost always false, so it's a tiny tiny tiny bit faster to notice immediately that the first condition is false instead of checking first that validate==true and only then checking the condition.

The function validates the name chars and name length. Since validate pertains only to length, let's call it validate_view_name_len.

Ok, I'll change it.

I'll just call this one (and below) validate_len. I'm not a fan of super-long names, and the "view_name" (and below, "lsi_name") is redundant because that's the name of this function

With table_name and index_name also here it's still not immediately clear, but I'm close to being unreasonable on this. So let's go your way.

Let's rename validate into validate_lsi_name_len.

Renamed to validate_len ("lsi_name" is already the function's name, it doesn't help to repeat it).

I don't get it, why do you make executor::update_table stop checking the resulting lsi name length altogether?

The code adds a GSI (you can only add a GSI in UpdateTable) so it already validates the validity of the GSI name. It was never the intention of this code to check if it's a valid LSI name and report an error about a bad LSI name. The only intention was to try to check if an LSI of this name exists (and if it does, report an error). So we want to look up what an LSI with that name have as its name, without validation.

Note that whether or not the lsi_name() function validates valid characters is not important - we already validated them in gsi_name() earlier. The only place this change ever matter is when the length of the table name plus index name plus 1 is exactly 222 - because this is a valid GSI name but not a valid LSI name (because of the silly reason that we used two characters instead of one as a separator for LSIs).

That's clear, thanks.
Although it would be more prudent to design the lsi_name() with a parameter bool validate (the name you had there before) that would enable/disable all validations, not only the length - ultimately that's what is aimed here - just gimme name, no validation!

Let's call max max_gsi_name_len instead.

I think "max_gsi_name_len" sounds too general - it sounds like it might be the maximum allowed gsi name length for all GSIs, which isn't true - this is only the maximum for GSIs of this specific table (the formula subtract this table's length from it).
In any case, I think that after a 3-line comment explaining what "max" is, a shorter name is fine. The comment explains much better than a name of any length could have explained.

"max_gsi_name_len" sounds too general - it sounds like it might be the maximum allowed gsi name length for all GSIs

I don't agree, the variable is local, so is its context. And it's better than the general max.

This test has 4 lines of code, and 3 lines of comment explaining what "max" is. I honestly don't understand why its name matters.

But moreover, I argue that "max_gsi_name_len" is a wrong name, because it suggests there is some "maximum gsi name length" while there isn't such a thing, there is only some maximum size related to this test. I prefer the reader doesn't know exactly which "max" this is an reads the comment, over the user thinking the variable name is self explanatory and coming to the wrong conclusion!

256, not 255

Yikes, you're right. Turns out I forgot to run this specific test on AWS, so I missed this copy-pasto :-( The test as written with 255 fails on AWS, because GSI name length 255 is allowed on DynamoDB, not forbidden. (on Scylla it's forbidden - even shorter names are forbidden - so this test passes.

I suspected that in the end you did not run this against AWS, otherwise you would have caught that yourself.

Let's call max max_gsi_name_len instead.

See my answer above about "max"

Let's call max max_lsi_name_len instead.

ditto

Why not create_and_delete_table here too, especially that the top-level function name promises it? I know this will raise, but suppose it does not raise for some reason.

Yes, makes sense. I don't remember why I did it this way.