You can't have sqlite3_bind_subtype() because it would require a change to the database file format - there would be no real performance penalty besides increased record size. There is no existing place to store a per-value subtype in the file format as it stands, although I did have a design that would hide a few bits for the subtype at the end of the record header where no-one is looking. It is a hack though and I gave up becuase of having to also implement passing around the subtype internally, which was then solved with the above functions, but by that time I had moved on to a different solution. If you're really interested I can probably describe the hack as I originally envisaged it.
Anyway, that's one theory, the other is that Richard isn't updating the file format just to spite me for rudely arguing the need for subtypes a couple of years ago. That or he just values the stability of the file format. > On Jul 24, 2017, at 2:40 AM, petern <[email protected]> wrote: > > 2. These functions convey only the lower 8 bits of information and there > there is no corresponding sqlite3_bind_subtype() but there is mention of > expanding the number of bits in future SQLite versions. I take it the > present 8 bits API can't be extended to a new sqlite3_bind_subtype() > function for performance reasons? Even 8 bits could hash a modest cache of > application pointers. Just asking. > _______________________________________________ > sqlite-users mailing list > [email protected] > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
