Hi Clemens,
Even though the documentation makes no guaranty about the lifetime, it is was
also for me rather useless.
I need to do some spatial calculations in my custom SQL function, and use the
proj4 projection library within it. This SQL function is called very often, and
having to
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
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
Clemens.
Here it that example again, but with the argument factored out so there is
no question about value or memory location of the cache argument target.
Remarkably, caching doesn't work at all when one does this!
sqlite> WITH arg(x) AS (SELECT 'x'), t(id) AS (VALUES(1),(2)) SELECT
>The auxdata is intended as a cache, so it must depend only on the
>argument value, not on any other state.
I'm not following. Where is the argument different in my example. The
zeroth argument is always 'x'. Are you saying the argument has to be the
same memory location as well as the same
petern wrote:
> So, at the very least, the documentation at
> https://sqlite.org/c3ref/get_auxdata.html is woefully incomplete because:
>
> 1. The identical function in a different column of the same SELECT has a
> separate meta-data cache.
This is an implementation detail of the current version.
6 matches
Mail list logo
