> Le 8 mai 2017 à 23:11, petern <peter.nichvolo...@gmail.com> a écrit : > > Gwendal. I understand all that. It's also good that you've confirmed how > SQLITE_READ is actually queried by the authorizer callback interface. I > was wondering about that. Reading your earlier post, one might get the > impression that the SQLITE_READ authorizer action was not queried by the > engine for aggregate table reads for some reason. Presumably that would be > a bug. > > My question about your solution is illustrated by looking at the existing > defines for orthogonal operations. Consider how SELECT, INSERT, and UPDATE > are currently defined as below. > > #define SQLITE_INSERT 18 /* Table Name NULL > */ > #define SQLITE_SELECT 21 /* NULL NULL > */ > #define SQLITE_UPDATE 23 /* Table Name Column Name > */ > > If this interface is logically missing SQLITE_READ_TABLE then shouldn't all > the orthogonal authorizer action codes in that same dimension also be > implemented? Thus, why not also add authorizer action codes for > SQLITE_WRITE_TABLE, SQLITE_READ_COLUMN, SQLITE_WRITE_COLUMN, > SQLITE_READ_SCHEMA, and SQLITE_WRITE_SCHEMA? Why only just > SQLITE_READ_TABLE? If SQLITE_READ_TABLE is missing why aren't the others > also missing?
Because they are not missing: existing authorizer callbacks already provide a detailed information for all possible updates. We just miss information about selected tables. > Why is this forum so silent on this question? Usually there are half a > dozen responses on the "correct way" to do it. This time, crickets. I did propose a patch as a way to show that my proposal doesn't come from thin air, but can be implemented. Yes, I wish the core team would give at least an acknowledgement that something could be improved. Gwendal Roué _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
