Alex Katebi wrote:
Hi All,
For those of us that use SQLite mostly in-memory. Our context is mostly not
{sqlite3*} database pointer, it is {sqlite3_stmt*}.
Current API?
int sqlite3_set_authorizer(
sqlite3*,
int (*xAuth)(void*,int,const char*,const char*,const char*,const char*),
void *pUserData
);
Can we add the following API in the future?
int sqlite3_stmt_set_authorizer(
sqlite3_stmt*,
int (*xAuth)(void*,int,const char*,const char*,const char*,const char*),
void *pUserData
);
Why overload the API when you could simply use sqlite3_db_handle? Pass
it the your sqlite3_stmt* and you'll get the sqlite3 * to which your
prepared statement belongs. You could even (ab)use the preprocessor to
redefine the authorizer callback setter to always implicitely call
sqlite3_db_handle (I personally dislike preprocessor magic that violates
the principle of least astonishment, but you expect to be the sole
maintainer for the code it's very much OK.)
I have a user interface RPC for my application that configures and gets
status from my in-memory server database.
That sounds like you are using raw pointers as handles passing them to
remote consumers. If at all possible, I recommend you avoid this
practice - it's terrible from a security standpoint, and it's
questionable from a robustness standpoint. User mode pointers should be
considered valid only within their defined domain, i.e. the address
space of the process, and any type of pointers (including kernel
pointers) should be considered valid only on the local machine.
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
