I am drawing from parallel functionality in the existing API. Roughly, the API sqlite3_buffer_numeric_type() would simply be the buffer input version of the existing API sqlite3_value_numeric_type(). But instead of operating on a sqlite3_value parameter, it would read from a pzBuffer parameter (plus optional length and optional encoding) to return one of SQLITE_FLOAT, SQLITE_INTEGER, or SQLITE_NULL by directly calling on the internal recognizers.
On Tue, Jan 23, 2018 at 6:09 PM, Richard Hipp <d...@sqlite.org> wrote: > On 1/23/18, petern <peter.nichvolo...@gmail.com> wrote: > > Any chance of publishing a modest but hardened "int > > sqlite3_numeric_buffer_type(const char*pBuffer,int length,int encoding)" > > API that extensions can use? > > I'm not sure what "sqlite3_numeric_buffer_type()" is suppose to do? > -- > 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
