Your proposal does not walk through the alternative of sticking with subtypes to add non-persistent sqlite3_bind_subtype() and corresponding sqlite3_column_subtype() methods. With a few extra lines and some imagination can't this more straightforward alternative be combined with the existing BLOB pointer interface to reach the desired outcome in FTS and carray?
BTW, if the hypothetical attacker has a copy of the application, aren't the constant space pointer access keys' string addresses all there in clear text. The castle walls will be no higher than those of a discretionary pointer access protocol with subtypes. In fact, subtypes could afford greater security at runtime if the programmer rotates or otherwise randomizes the type id's. On Mon, Jul 24, 2017 at 10:05 AM, Richard Hipp <d...@sqlite.org> wrote: > On 7/24/17, petern <peter.nichvolo...@gmail.com> wrote: > > > > Are sqlite3_result_subtype() and sqlite3_value_subtype() being deprecated > > in light of the duplicate functionality? > > > > No. The subtype() interfaces were originally created for completely > unrelated purposes (specifically to identify validated JSON text in > the JSON1 extension) and will continue to live on to serve those > unrelated purposes. > > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > 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
