On Mon, Dec 01, 2008 at 09:45:39AM -0800, Liane Praza wrote: > >Binary size for configd is not likely to be a problem. Using SQLite3 > >would be a very good thing indeed. I figure the SMF team will cringe at > >the idea of linking with a shared SQLite3; we'll see! > > I don't inherently cringe. (Others might, but they can speak for > themselves.) It's the fact that sqlite3 has an entirely different > library API, plus the extensive retesting that would be required that's > kept us from prioritizing the work since there would be no > administratively visible benefit from the switch. But, I have no reason > to discourage someone from exploring it.
OK. Good! BTW, the API doesn't differ that much. The main addition is the ability to bind values to parameters in compiled queries (that was an experimental API in SQLite2), which greatly limits the scope for SQL injection attacks AND improves performance by allowing you to compile queries once and re-run them many times (which you can't do with the old sqlite_exec() approach if constant terms in your queries had to vary contextually). > (SMF's not the only consumer of sqlite2 in ON though, I thought. > Removing SMF's use wouldn't change the other consumers' needs.) Indeed.
