Nothing like sticking your neck out, eh? :-) One of the major improvements in 4.7 is the data-driven Forms API. Instead of having modules generate/munge form HTML directly, they generate and return a data structure describing the form they want. This leads to all kinds of benefits I don't need to enumerate here. Another major improvement in 4.7 is hook_install() and hook_update_N() which allow modules to programatically create and modify their own tables. Good stuff, but the modules must maintain separate code for MySQL and Postgres and generate/munge their tables directly. IMHO, _install() and _update_N() are to 4.7 what the pre-Forms API form-building techniques were to <=4.6. So, why not create a data-driven table creation/modification API? I'm not proposing a complex abstraction over all possible data storage mechanisms, just something that is enough to generate "CREATE TABLE" statements for MySQL and Postgres and, more importantly, allows Drupal to reflect on its own database scheme. Now that I think about it, I bet CCK has something like internally already. I haven't looked inside CCK yet. Very roughly, I'm envisioning something like this: function modulename_schema() { $tables['event']['#charset'] = 'utf8'; $tables['event']['nid'] = array( '#type' => DB_INT, '#dispwidth' => 10, '#signed' => FALSE, '#null' => FALSE, '#default' => '0'); $tables['event']['event_start'] = array(...); ...; return $tables; } This will provide numerous other advantages, most of which I probably haven't thought of. One would be to more cleanly control scheme changes for updates. One option would be to include a '#schema' version number field. For simple new columns, the Database API could execute the ALTER TABLE itself. For more complex changes, the module could specify a callback. Obviously the idea would need to be fleshed out more. If there is interest and is not already being done, I'll take it on (or at least get it started). Comments? Barry