6.x-2.10 conditionally wipes all data from a given view

Looking at the save_row function in includes/views.inc:

<?php
    $schema = drupal_get_schema($this->db_table);
    $fields = $defs = $values = $serials = array();

    // Go through our schema and build correlations.
    foreach ($schema['fields'] as $field => $info) {
      // special case -- skip serial types if we are updating.
      if ($info['type'] == 'serial') {
        $serials[] = $field;
        continue;
      }
      $fields[] = $field;
      switch ($info['type']) {
        case 'blob':
          $defs[] = '%b';
          break;
        case 'int':
          $defs[] = '%d';
          break;
        case 'float':
        case 'numeric':
          $defs[] = '%f';
          break;
        default:
          $defs[] = "'%s'";
      }
      if (empty($info['serialize'])) {
        $values[] = $this->$field;
      }
      else {
        $values[] = serialize($this->$field);
      }
 // ..
?>

I can get views to work again if I change:

<?php
 switch ($info['type']) {
        case 'blob':
          $defs[] = '%b';
          break;
?>

to:

<?php
 switch ($info['type']) {
        case 'text':
        case 'blob':
          $defs[] = '%b';
          break;
?>

So, for some reason sending the text as a %b prevents the string from breaking.
Looking at the database differences for when I insert "/^http:\/\//i" into some arbitrary field for both when text is treated as %s and when treated as %b:
%b: s:15:"/^http:\\/\\//i"
%s: s:15:"/^http:\/\//i"

With my curiosity increasing, I tried the string: "/^http:\\/\\//i"
%b: s:17:"/^http:\\\\/\\\\//i"
%s: s:17:"/^http:\\/\\//i"

Interestingly, the second %s case did not return valid data as did the first %b case.

I then changed the last bit of the shown code to look like:

<?php
      if (empty($info['serialize'])) {
        $values[] = $this->$field;
      }
      else {
        if ($info['type'] == 'text'){
          $values[] = str_replace('\\', '\\\\', serialize($this->$field));
        } else {
          $values[] = serialize($this->$field);
        }
      }
?>

If the serialize is done before the string replace, then this works, but if the serialize is done after the string replace, then the same problem occurs.

So it seems that the backslash '\' needs to be delimited for string types.
During the update, when the data type was changed from blob to text, all of the resulting text did not get the '\' delimited and as a result produce unexpected behavior on load.
Should the string replace be applied to the non-serialized data as well?
Is arbitrarily delimiting the '\' after a serialize command the proper solution here (or safe)?
This also begs the question of is there a security issue here?

Here is the change from #5 in patch form.

Please Review.

Thats what concerns me with %b. Doesn't it convert other things than just quotes?
(Granted those other things probably should not appear in a normal "string" type anyway.)