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 recreate the proj4 object with projection params each time was a huge 
performance issue for me. I wasn’t able to figure out when the data was 
actually cached – during my tests I simply got the free callback fired 
immediately after each step. 

I also had a second use case which actually requires a guaranty for the aux 
data to exist (providing the current position of a 3D camera. Somewhat 
comparable to a date function – you get current data whenever you call it).

I eventually hacked the VDBE struct, added a pointer to it, and altered some 
places in order to be able to pass a pointer to the sqlite3_step which I then 
retrieve from the custom sql function from the context via something like 
sqlite3_get_custom_ptr. 

I would call my implementation a hack, though I simply required the performance 
improvement and the guaranty for the instance be available whenever the 
function gets called. It would be great if there was a (probably new) API which 
does that in a proper way.

Regards
Ben

Am 27.11.17, 22:28 schrieb "sqlite-users im Auftrag von Clemens Ladisch" 
<sqlite-users-boun...@mailinglists.sqlite.org im Auftrag von 
clem...@ladisch.de>:

    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

Reply via email to