I totally agree with your answer. But this wasn't really the question. > You have hacked around this security feature
I beg you to try to look at my "hacks" with a fresh eye. The service they provide is a genuine one: be able to run raw SQL requests, and also to be notified when one has committed changes in the results of another. I suppose you know that most high-level libraries in GUI platforms embed such database observation features. This is part of the expected tool belt these days. It happens that a security feature has been rerouted for another purpose. This other purpose sheds a new light on authorizers. In GRDB, statements are always "authorized": applications want to manage *their* database, so there is no point restricting access to the database. There is no need for the security side of SQLite authorizer. There is need for the statement inspection features provided by SQLite authorizers (what will be read/written). And prevention of the truncate optimization. Now that I hope I have better explained where I talk from, I hope you will read again my previous question. Thanks in advance, Gwendal Roué _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
