Codecov Report

❌ Patch coverage is 98.05825% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.02%. Comparing base (8784e5f) to head (643d581).
⚠️ Report is 19 commits behind head on master.

@@            Coverage Diff             @@
##           master    #1626      +/-   ##
==========================================
+ Coverage   87.96%   88.02%   +0.06%     
==========================================
  Files          58       58              
  Lines       10648    10733      +85     
==========================================
+ Hits         9366     9448      +82     
- Misses       1282     1285       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

SQLite destructor provides only the raw pointer but:

• to deallocate a Vec<T>, you also need its length and capacity
• to deallocate a Box<[T]>, you also need its length

Only Rc<[T]> can be deallocated with only the raw pointer.

Official JNI uses a global ref:
https://github.com/sqlite/sqlite/blob/d75acb8312a6aacd5cccecf46781e44348bf2a43/ext/jni/src/c/sqlite3-jni.c#L2675C24-L2678

Does SQLite need to take ownership of the pointer (i.e. can this be made to use a slice ref instead of an owning vec/box)? That would remove the need to deallocate altogether.

Alternatively, a vector of tuples of (ptr, len, capacity) can be stored within the connection itself and binary searched for a match in the free stage; it would be zero-alloc for an empty vec and the 24-byte field itself would only be included in each Connection object if you are using the array feature?

Currently, you cannot retrieve the Connection from a VTabConnection / *mut sqlite3 so you will not be able to destroy the owned pointer.
There is also this API:
https://sqlite.org/c3ref/get_clientdata.html
But still, only a void* pointer, not (ptr, len, capacity).