>> 2. In case the virtual table implementation needs to allocate memory in >> order to uniquely >> describe a row/item, this memory needs to be freed when no longer used. As I >> see it, there is no >> such method in the Virtual Table implementation. > >Maybe the transaction part of the virtual table API is useful in >this context (xBegin/xSync/xCommit/xRollback). SQLite will only store >values retrieved via xRowid for the duration of a transaction. So >if you need to create a mapping between the integer id's used by >SQLite and the complex identifiers, you can throw the table away >at the end of the transaction. > >A linked list and a willingness to cast pointers to 64-bit integers >seems like it would do the trick :)
This willingness is certainly there, but with many thousand modifications in a single transaction, this would accumulate a couple thousant memory allocations and free them only after the transaction is committed. Very ineffective, in my opinion :( >Of course that won't help with sqlite apps that expect the rowid >field to remain persistent between queries that span multiple >transactions (i.e. MS Access style GUIs etc.). Correct. Quite a few DBMS simply do not use and support the concept of integer rowids. The current xRowID implementation would not allow to access those as virtual tables from SQLite. To support those as well, I believe that the SQLite type integer rowids could be made optional for virtual tables and another, more flexible approach could instead be made available (as proposed in my previous mailing). This would of course mean that those virtual tables would not have a rowid column and SQLite would return the usual 'No such solumn: rowid'. But I do not see any problems to this from a user's perspective.
