Are we sure we want to support it "by default"?
As far as I've seen in the last few months, it's both not very suitable for any kind of forum (unless you have 3 users and you post 5 messages a month) and is quite a security risk (many people don't realise the database can be downloaded by anyone if not properly configured).
I understand it could be useful in some circumstances, but I'm leaning toward considering a nice "add-on" rather then a "core" feature...
I didn't realise it was that bad!
I've seem issues with just about 4000 messages (a lot of issues to the point that the admin has to delete older messages just to keep the forum up) on a semi-private forum.
Yes, it may be the server (I know nothing about its configuration, not even the host), though the other forum was just "slightly" bigger (~10k AFAIR).
Also the only SQLite we are support at the moment (2.x) has been removed from PHP 5.4 (okay, this will take a while to become significant... ::) :P).
I''d bet the number of SMF installations with PostgreSQL or SQLite is < 1%
To be honest, I'd drop both and prepare for PDO instead.
The number of "PostgreSQL and SQLite Support" topics at simplemachines.org over the past 5 years clearly indicates that SMF boards using PostgreSQL or SQLite are very rare. If the actual statictics confirm that the percentage is that low, it is even arguable to support these as an add-on.
It doesn't help that the statistics are also vastly out of date, something we should fix in Elk and maybe have the statistics public :P
Statistic collection has been removed a long time ago. ;)
I have been saying that since Compuart added that garbage in there. Get rid of them both. Why waste time trying to get them to work?
The abstraction helps because there are currently 3 MySQL libraries that people use - mysqli, PDO (on top of mysql), and mysql. If you are going to work on it, add in prepared statements and async queries. They can both be emulated where they aren't available. Prepared statements are almost there. Just take the arguments that get passed to the functions anyway.
This has been moved "outside", so no more relevant.