node_privacy_byrole problems

I decided to diable node_privacy_byrole and try "simple access" instead. But now the changes that node_privacy_byrole made are still there even after disabling it.

Does anyone know how to undo the changes made by node_privacy_byrole?

I just found this buried in the .module file (it should be in the readme...).

Does the following comment mean that I have to use the following SQL to get rid of this module?
INSERT INTO node_access (nid, gid, realm, grant_view, grant_update, grant_delete) VALUES (0, 0, 'all', 1, 0, 0)';

Do I have to manually use the first SQL statement to get the module to work correctly? (DELETE FROM node_access WHERE realm='all';)

The readme file for the module does not mention any of this.

/**
 * @file
 * READ CAREFULLY!!!
 *
 * This module, when enabled, allows users to select which roles will
 * be allowed to view their posts.
 * 
 * The module uses hook_nodeapi() and hook_node_grants() to enable this 
 * functionality.  hook_nodeapi() provides formitems for the content creation 
 * page and content editing page as well as functionality that saves the user's 
 * preferences as selected via the formitems.  These preferences are saved into
 * the node_access table.
 * 
 * hook_node_grants() returns an associative array of permissions based on the 
 * operation ($op) and the global $user (even though the $user is a parameter 
 * to the hook, it is ignored at this point in time).  The _node_grants() hook 
 * is called by node_access(), a function in node.module, which is called whenever
 * a node operation is called.
 *
 * The concerns that follow are addressed via an extra settings page for the 
 * node_privacy_byrole module where the extra steps described below are carried 
 * out by a more explicit enabling/disabling functionality in the settings page. 
 * Ideally, the DB code in the settings page would automatically execute when the
 * module is enabled/disabled.  However, because Drupal does not provide hooks
 * at this time for tasks that should only happen upon disabling or enabling a 
 * module, we require the site admin to go to the settings page where the module 
 * can be properly initiated or disabled.
 *
 * For this module to be enabled properly, the following query must be performed 
 * against the database.
 * Database definition:
 * @code
 *   DELETE FROM node_access WHERE realm='all';
 * @endcode
 *
 * For this module to be properly disabled, the following query must be performed.
 * 
 * @code
 *   INSERT INTO node_access (nid, gid, realm, grant_view, grant_update, grant_delete) VALUES (0, 0, 'all', 1, 0, 0)';
 * @endcode
 *
 *
 * PROPER ENABLING OF MODULE
 * ---
 * The DELETE SQL statement above deletes the default access permission which 
 * automatically gives all users view permission for every node (while edit, 
 * and create permissions are determined by other code in node_access() in 
 * node.module).  This delete must take place since node view permissions are 
 * now being determined by this module, otherwise node_access will always return
 * TRUE for any user trying to view a node.  It must be executed when the module 
 * is enabled in order to let the module's _node_grants() function solely determine
 * which users have view permissions on a node-by-node basis since we are allowing
 * users to specify which roles can view a node on a node-by-node basis.
 *
 * ADDITIONALLY, code must be executed that essentially does the following when the 
 * module is enabled:
 *
 * for every ($node in node table) {
 *   for every ($role in role table) {
 *     INSERT INTO node_access($node->nid, $role->rid, 'node_privacy_byrole_role', 1, 0, 0);
 *   }
 *   INSERT INTO node_access($node->nid, $node->uid, 'node_privacy_byrole_user', 1, 0, 0);
 * }
 *
 * Before the module is enabled and the above DELETE SQL query is executed, every
 * node is viewable, by every user.  However, when the module is enabled and this
 * default is erased, we still want every node to be viewable by every user until
 * each node's creator decides to change that.  We also want each node's creator
 * to have view permissions to all the nodes s/he created (currently, node_access()
 * as defined in node.module, does not, by default, grant view access to a node's
 * creator.  It relies on the deleted default node_access table entry to provide
 * that permission).  
 *
 *
 * PROPER DISABLING OF MODULE
 * ---
 * The single INSERT SQL statement above is meant to reset to the default permission 
 * of allowing all users view permission for every node. 
 *
 * Again, ideally, these queries would be automatically executed when the module is
 * enabled or disabled.  However, at this point in time, drupal does not provide
 * hooks that  automatically execute upon the enabling/disabling of a module.
 *
 * Finally, there is the issue of what to do when a site admin enables this module,
 * disables the module, and then re-enables the module.  To account for this 
 * possibility, we must make sure none of the inserts described above is replicated.
 * Perhaps the site admin wants the permissions set during the first enabling to be 
 * valid after the re-enabling.  Either way, care must be taken not to duplicate the 
 * inserts from the first enabling, or to delete them from the DB altogether before 
 * doing a new set of inserts.  This is an open design decision.
 *
 * In this module, we've taken the path of inserting view permissions for every role
 * in the case of each node that has been created the previous disabling of the module.
 */