Update db_create_table() spec

This looks good. As Barry says, it simplifies the update hooks.
I tested both a new installation, and the changed menu update hook. No problems.
Rerolled with $tblname replaced with $tablename, no other changes. RTBC!

I would name $tablename simply $name... This a parameter to a function which deals with tables, so it is just logical that the name if of the table. Of course I see there are $name variables used elsewhere in the functions, those should be renamed appropriately. It is also not described, why there is a menu schema glaring at us in this patch.

Does it really matter wether it's called $name or $tablename? IMO, $tablename is actually better than $name, as we're also dealing with fieldnames and keynames here. But c'mon, now this really really minor nitpicking.

Regarding the menu schema: Currently, in the concerned update hook, we include the menu schema from hook_schema. However, with our current update/schema system, we cannot do that, as we don't know in which state the schema to which we refer is at the time of updating. Imagine we added a field to the menu table. We'd update menu_schema and write an update function for it. If you'd now run update.php, the /current/ schema would be created in the update hook in this patch, and following updates would fail. This is a little difficult to explain, see also http://drupal.org/node/144765#comment-245805 .

Proper explanation about why there's a menu schema glaring at us in the patch: http://drupal.org/node/150220

1. As I said, I think $name is better. If you ask Dries, he will say that we don't tack names together like $tablename, we rather do $table_name, but then again, we try to simplify things, so if we have a table function with a $table_name parameter, that redundancy does not make sense. If you don't accept my judgment, we can await Dries coming around, in the hopes that I have a bad estimation of what would he say. Three of your five modifications around table names have $name for the table name, two have $tablename. This is not consistent. The fact that there is $keyname or $fieldname in the existing code does not make this anything batter, it makes the existing code look worse regarding Drupal coding conventions. This is not an acceptable argument.

2. Great that we have a documentation link finally. Thanks.

1. As I said, I think $name is better. If you ask Dries, he will say that we don't tack names together like $tablename, we rather do $table_name, but then again, we try to simplify things, so if we have a table function with a $table_name parameter, that redundancy does not make sense. If you don't accept my judgment, we can await Dries coming around, in the hopes that I have a bad estimation of what would he say. Three of your five modifications around table names have $name for the table name, two have $tablename. This is not consistent. The fact that there is $keyname or $fieldname in the existing code does not make this anything batter, it makes the existing code look worse regarding Drupal coding conventions. This is not an acceptable argument.

2. Maybe you can also point to a documentation page which says this is how we should do updates? Note that I am not arguing against doing it, I understand that bjaspan knows how this should be done. I merely try to double check that others could have insight on why this happens and others can do proper updates. A (perfectly clear) comment on an issue is not too future proof as documentation.

Patch with $name instead of $tablename attached. Docs for creating tables in update hooks are here: http://drupal.org/node/150220

Seems Gábor commited this: http://drupal.org/cvs?commit=71551

Note, I did have a fix for the menu schema in the system update function in this patch, so it's not that the problem was unnoticed: http://drupal.org/node/147657

Yeah, it was committed, but the drupal.org DB was down just at that time, so I was unable to close the issue.