There is no sqlite3_result_subtype() becuase there is no sqlite3_bind_subtype() becuase the subtype of a value cannot be stored in the database. That is my point. I don't know what you mean by your second paragraph, but subtype here is just an attribute of a value, similar to it's type (in SQLite each stored value can have its own type). Given SQLite is a database, it seems natural to be able to store a value's subtype along with the other attributes of a value, but for whatever reason the SQLite devs did not think that was nessessary.
> On Jul 24, 2017, at 7:57 AM, petern <peter.nichvolo...@gmail.com> wrote: > > 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 <li...@darko.org> 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 <peter.nichvolo...@gmail.com> 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 >>> sqlite-users@mailinglists.sqlite.org >>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >> >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@mailinglists.sqlite.org >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >> > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
