Users of a sqlite3_bind_subtype() wouldn't expect those bits to be persisted to disk considering that a function returned column value presented to INSERT or UPDATE doesn't have sqlite3_result_subtype() bits recorded. Does that make a difference to your answer?
https://www.sqlite.org/c3ref/result_subtype.html Subtypes as currently implemented are only useful for coordinating type safety among the application's transient objects. I certainly wouldn't expect to read back hidden subtype bits from the disk to initialize/deduce a transient object's type. In the interest of readability and transparency the design of the ordinarily visible part of table name and columns themselves would always fully encode the type of transient objects based on that table's rows. Encoding stuff in persisted hidden column bits works against the "correct by inspection" objective of good design. On Sun, Jul 23, 2017 at 9:13 PM, Darko Volaric <[email protected]> wrote: > 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 > _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
