... > > size -- both code and RAM. I know about the various > compile switches that > > can turn off various features, but I wonder if I can really > strip it down > > further by eliminating parsing, query planning, etc, > altogether, and only > > support the virtual machine. I do need virtual tables, > though. In my > > particular use-case, I only need read access -- no create > or update. The ... > > such that it will still work on memory-constrained devices > (e.g. having a > > total of 128 KiB max for the whole system). > > > > Anway, has this been discussed before? Or is it a fool's errand? > > We did this once, back in 2005, for a startup company in Boston. It > was called "SSE". Unfortunately, we didn't continue to support it. I > went looking for the source code and could not find it. > > The database was to run on a smart-card with limited RAM. All of the > prepared statements were generated on a workstation, then serialized > and stored in a special table in the database file. The application > would then use a special API that would deserialize a prepared > statement (identified by a well-known integer) then bind parameters > and run it. > > So much has changed in the SQLite bytecode engine since then that > there is basically zero chance that SSE would still run today, even if > I could find the source code. > > -- > D. Richard Hipp > d...@sqlite.org
Ah, groovy. Well, at least that is validation of the concept. So it sounds like I have a side project for my copious free time! -dave _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
