No way to insert NULLs using argument substitution (fix suggested)

I have a situation where I have numbers entered by a user, but some of them are optional. If the user does not enter them, I want to insert NULLs into the database. I figured if I passed a null instead of an int, that a null would get inserted, but instead, the integer 0 gets inserted.

I've tracked this problem down to _db_query_callback in database.inc. It seems to be an intentional (if not beneficial, at least in this case) design decision, because the argument is cast to an int. The comment given is:
// We must use type casting to int to convert FALSE/NULL/(TRUE?)
Well, true and false I understand, but NULL has a meaning in an integer column; it means null!

I would purpose we change _db_query_callback so that if the arg is null, it returns 'NULL'.
For example:

 case '%d': 
      $arg = array_shift($args);
      return $arg === null ? 'NULL' : (int) $arg;

This works fine for integers and floats, but unfortunately, it won't work for strings, because the string would still be quoted in the sql, resulting in the string 'NULL' instead of NULL. For it to work on strings, we would need to make the regex match the quote marks as well as the %s.

It seems like it might be better to automatically insert the quote marks around the %s instead of having the user type them, e.g. db_query("INSERT INTO {table} VALUES(%s)") instead of db_query("INSERT INTO {table} VALUES('%s')"). With this patch the old usage would be supported, but deprecated.

So we could expand the regex:
define('DB_QUERY_REGEXP', "/(%d|'%s'|%s|%%|%f|%b)/");

Then the string portion of _db_query_callback would read

case '%s':
case "'%s'":
      $arg = array_shift($args);
      return $arg === null ? 'NULL' : "'" . db_escape_string(array_shift($args)) . "'";

I have modified my database.inc as such and it generally works fine, although I have encountered one case where the old behavior was relied upon:

user warning: Column 'link' cannot be null query: watchdog INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (3, 'page not found', 'test', 1, NULL, 'http://mysite.com/asdf', NULL, 'x.x.x.x', 1193253537) in /var/www/drupal/includes/database.mysql.inc on line 172.

The replacement code works properly, but watchdog was relying on the old behavior, where one could pass a null and an empty string would be inserted instead. Probably there would be a number of small changes required. They're simple, but they would have to be tracked down.

What do you all think about using "%s" instead of "'%s'" in query strings? It seems cleaner to me to write VALUES(%d,%s,%d) rather than VALUES(%d,'%s',%d), but maybe there is a reason for the old way that I don't know about.

This is the first time I've tried to submit a patch, so please let me know what you think. Give me advice! I look forward to your responses.

P.S. I patched this against HEAD, as requested, but I only actually tested it against Drupal 5.3. It looked like none of the relevant code had changed, so I think it should work the same on both versions.

Nick