Title: bilbo's Replies | WordPress.org

---

# bilbo

  [  ](https://wordpress.org/support/users/bilbo/)

 *   [Profile](https://wordpress.org/support/users/bilbo/)
 *   [Topics Started](https://wordpress.org/support/users/bilbo/topics/)
 *   [Replies Created](https://wordpress.org/support/users/bilbo/replies/)
 *   [Reviews Written](https://wordpress.org/support/users/bilbo/reviews/)
 *   [Topics Replied To](https://wordpress.org/support/users/bilbo/replied-to/)
 *   [Engagements](https://wordpress.org/support/users/bilbo/engagements/)
 *   [Favorites](https://wordpress.org/support/users/bilbo/favorites/)

 Search replies:

## Forum Replies Created

Viewing 1 replies (of 1 total)

 *   Forum: [Everything else WordPress](https://wordpress.org/support/forum/miscellaneous/)
   
   In reply to: [WP and database agnosticism](https://wordpress.org/support/topic/wp-and-database-agnosticism/)
 *  Thread Starter [bilbo](https://wordpress.org/support/users/bilbo/)
 * (@bilbo)
 * [19 years, 1 month ago](https://wordpress.org/support/topic/wp-and-database-agnosticism/#post-552637)
 * Thanks for the reply. It does seem that multiple database support was in the 
   plans at one time.
 * The reason that I asked the second question is that, while I could write a “forked”
   version, I have no desire to create an offshoot of WordPress. I would prefer 
   to see a unified version that was not tied to one database, however applicable
   that database might be. I have been looking into doing exactly that (though it
   is not trivial by any means). If such a task were to be performed, would they
   simply shrug it off though as “nice, but not really useful?”
 * I understand what you mean regarding SQL dialects. One solution to that would
   be to abstract any SQL into the data access layer and create methods that WP 
   used, such as `$wpdb->get_posts_for_date('<some date>')` instead of `$wpdb->query("
   select * where date='<some date>')`.

Viewing 1 replies (of 1 total)