Clemens, Indeed. It doesn't work as a basis for reliable performance improvement of user code. Basically, that API is practically useless except for the narrow in-house use case for which it was created. And yes, I already make heavy use of the natural aggregate cache functionality but for the limitation of only producing only one final output value. A statement level function cache obviously has more general use.
So, as I pointed out to Ben, the other poster who also discovered the limitations of sqlite3_get_auxdata(), it would be trivial to get the desired statement level cache speedup if only there were a per-connection version of the API, say sqlite3_set_data(sqlite3*,void*) and void* sqlite3_get_data(sqlite3*). A connection level data area is definitely missing from the API. To implement one's own thread aware global connection to cache map wrapper seems a lot to ask when it could so easily be added to the SQLite API. Such an SQLite API implementation has a huge advantage in already having an internal hash map implementation and total awareness of current operational threading mode of SQLite. That being said, there is still a documentation bug that is wasting people's time. A face value reading of the documentation at https://www.sqlite.org/c3ref/get_auxdata.html gives the impression that caching is solely dependent on the index and value of the function argument when in fact there are 3 more very important and unstated limitations. Documenting those limitations would only add one or two sentences but would save people a lot of time. Peter On Mon, Nov 27, 2017 at 1:27 PM, Clemens Ladisch <clem...@ladisch.de> wrote: > petern wrote: > > Evidently the sqlite3_get_auxdata() API is very buggy. > > The documentation says that > | under some circumstances the associated metadata may be preserved. > > You have found circumstances where the metadata is not preserved. > > This is not a bug. > > I can see that you are unhappy, but that is just because you are trying > to make it do something that it was never intended to do. > > If you want a function with mutable state over multiple invocations, > do not use sqlite3_set_auxdata() but an aggregation function, or store > the data elsewhere. > > > Regards, > Clemens > _______________________________________________ > 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
