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*

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 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.


On Mon, Nov 27, 2017 at 1:27 PM, Clemens Ladisch <> 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 mailing list

Reply via email to