I think the original idea was to be able to use WP with other databases and that was probably the intention of an “abstraction” layer. However, I’ve seen plenty of evidence where the concept breaks down and the actual SQL used is incompatible, like the “limit” clause, for instance.
I think somewhere along the line developers abandoned compatibility probably due to the wide acceptance that there’s nothing better than MySQL for web-based applications anyway, so why bother?
I’m not necessarily saying that’s right, I’m just guessing that’s how things evolved. While I think your idea of introducing more versatility is theoretically sound, I don’t think it will be of much use for the overwhelming majority of folks.
However, as WP is free software, you’re quite within your rights to make whatever changes you want under the terms of the GPL license and unleash your own “forked” version.
Thread Starter
bilbo
(@bilbo)
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>').