Using SQLite internal recognizers eg: SQLITE_PRIVATE int sqlite3AtoF()

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Using SQLite internal recognizers eg: SQLITE_PRIVATE int sqlite3AtoF()

petern
What is the fastest forward compatible way to gain use of the internal
buffer value recognizers such as "SQLITE_PRIVATE int sqlite3AtoF()" in
external C programs?

The goal is to efficiently compute exactly how SQLite would taxonomically
classify {numeric,float,integer,...} a buffer string value if it were used
in a statement.

Obviously the buffer under test could simply be composed into a "SELECT
typeof('$buffer')" statement and the result string read back from the db
exection step().  However prepare() + bind() + step() is slow compared to
directly calling natively compiled recognizer functions.

The computationally faster alternatives are (1) patch out SQLITE_PRIVATE on
the recognizer functions in a custom build to export them or (2)
copy/paste/fixup the recognizer function snippets into the external
compilation unit and hope they don't change too much.

What other alternatives are possible?

Peter
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Using SQLite internal recognizers eg: SQLITE_PRIVATE int sqlite3AtoF()

Richard Hipp-3
On 1/23/18, petern <[hidden email]> wrote:
> What is the fastest forward compatible way to gain use of the internal
> buffer value recognizers such as "SQLITE_PRIVATE int sqlite3AtoF()" in
> external C programs?
>

There is no forwards-compatible way to do that.  We reserve the right
to change the design and/or behavior of all internal interfaces at any
time and for any reason.  And we do.  Usually there are some internal
interface changes on every release.  With a quick glance, I count 10
separate, incompatble changes in the 3.22.0 release, with no telling
how many others I have overlooked.

Furthermore, the internal interfaces are not hardened for general use
and are not general purpose.  They will typically have quirks and
caveats and corner-cases that need to be avoided.
--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Using SQLite internal recognizers eg: SQLITE_PRIVATE int sqlite3AtoF()

petern
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?

On Tue, Jan 23, 2018 at 4:43 PM, Richard Hipp <[hidden email]> wrote:

> On 1/23/18, petern <[hidden email]> wrote:
> > What is the fastest forward compatible way to gain use of the internal
> > buffer value recognizers such as "SQLITE_PRIVATE int sqlite3AtoF()" in
> > external C programs?
> >
>
> There is no forwards-compatible way to do that.  We reserve the right
> to change the design and/or behavior of all internal interfaces at any
> time and for any reason.  And we do.  Usually there are some internal
> interface changes on every release.  With a quick glance, I count 10
> separate, incompatble changes in the 3.22.0 release, with no telling
> how many others I have overlooked.
>
> Furthermore, the internal interfaces are not hardened for general use
> and are not general purpose.  They will typically have quirks and
> caveats and corner-cases that need to be avoided.
> --
> D. Richard Hipp
> [hidden email]
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Using SQLite internal recognizers eg: SQLITE_PRIVATE int sqlite3AtoF()

Richard Hipp-3
On 1/23/18, petern <[hidden email]> 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
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Using SQLite internal recognizers eg: SQLITE_PRIVATE int sqlite3AtoF()

petern
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 <[hidden email]> wrote:

> On 1/23/18, petern <[hidden email]> 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
> [hidden email]
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users