I know this is not a bug. But Acyd mentioned to me at one point that some code suggestions could be reported here so I'm doing that now. (Not sure if this suggestion qualifies - if not, I apologize.)

Anyway, I see that db_tools.php automatically inserts NOT NULL whenever its sql_column_add() function is called (the NOT NULL part gets added when that function in turn calls the sql_prepare_column_data() function). Is there a reason why db_tools does that rather than giving an option to do that or not which could default to NOT NULL but could be overriden?

Because of this db_tools limitation - and because custom fields in the profile_fields_data table are set up to allow null - acp_profile.php does not use db_tools->sql_column_add to add its columns to the profile_fields_data table. Rather, its add_field_ident() function runs different queries depending on the database in use to add a new column that allows null in the profile_fields_data table. For example, here's the query it uses if the board is running on mysql:

$sql = 'ALTER TABLE ' . PROFILE_FIELDS_DATA_TABLE . " ADD `$field_ident` ";

Later in that file, that query gets appended with info about the type of column. For example, if the field is a text field, there's this:

					case FIELD_TEXT:

						$sql .= "TEXT";

I would have thought this would all be more straightforward if db_tools permitted a designation of allow null (since in that case acp_profile.php could use db_tools and would not need all that db specific coding). Moreover, that would make it easy for umil to allow mod authors to add fields that allow null. That would be useful, because otherwise when a mod author adds a new field to a table he needs to find every place in phpbb3 where rows get inserted in that table and edit those ocurrances to refer to the new field (which can sometimes be a pain).

Just a thought...