I wrote a module called cac_lite which provides simple access control for users of the category module. One of the things it does is rewrite sql queries where the $primary_field is 'cid' (category id). Now I've learned of another module (Comment RSS) that also calls db_rewrite_sql with $primary_field 'cid'. But in this case 'cid' stands for comment id. The effect is that cac_lite rewrites a sql query that it shouldn't rewrite. So users can't have commentrss and cac_lite installed together. The underlying problem is that implementers of hook_db_rewrite_sql have no accurate test for what the fully-qualified primary field is. They are passed a $primary_table, but this is usually an alias of the table's real name. For instance, when commentrss calls it, $primary_table is 'c' and not 'comments'. When category calls it, $primary_table is again 'c' and not 'category'. What's a module to do when it recieves two calls to hook_db_rewrite_sql; in both cases $primary_field is 'cid' and $primary_table is 'c', but in one case the query needs re-writing and in the other it does not? -Dave