[eluser]WanWizard[/eluser]
Eh... There is no user interaction with the session table, and the session library uses active record, which protects all your queries against SQL injection attacks by a proper escape mechanism. No need to do that yourself, that's the advantage of using a framework.
Especially for small sites the database solution is a lot better then PHP's native sessions, as the database engine is a lot more effecient in I/O then PHP's file I/O code. Also, all keys will be in memory, so it's going to be fast.
And you know what you should do with rumours...
Sessions work very reliably, I've got sites serving over 2 million pages (13 million hits) per month, and approx. 20.000 users registered. Which means a highly active session table. For high-volume sites, I have modified the session library slighly. Default, every set_userdata() call results in an update query. Which I switched off, I do a manual sess_write() when I reach the end of a page request, or just before a redirect(). For low volume sites, this is not an issue at all.