-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20/10/11 14:39, Peter Aronson wrote: > I'm porting code from DBMS platforms that have grants and revokes. One > of the functions gets a list of available tables and what SQL > operations you can perform on them (select, insert, update, delete). A > table in a database attached to read-only would have select privilges, > but a table in a database attached read/write would have all four.
You can't change the code now, but in the Python community there is talk of the look before you leap versus easier to ask forgiveness than permission idioms. ie check everything for doing the action versus just doing it and handling failure gracefully. I'd advocate moving to the latter idiom for several reasons. First is that it removes race conditions and similar kinds of changes happening underneath your feet. The second is that permissions are getting more and more complicated, and it gets harder and harder to tell if something would be allowed other than just trying it. > So, write a virtual table to that contains the information I've added > to the pragma? That's possible, but I'd still have to go inside SQLite > somehow to get the information in the first place. So, I'm not seeing > a lot of advantage here. The reason is that you can do SQL on virtual tables (eg SELECT ... WHERE) which makes it far more useful than a pragma. The other is that DRH has expressed a preference for virtual tables over pragmas in tickets where the issue came up. It is extremely unlikely that an existing pragma will be altered in the core SQLite code. You at least have a shot of a virtual table being added to SQLite. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6gus8ACgkQmOOfHg372QTG6wCdHqLmo5kUzNpxRsDaW5vfEtmH Ku8AoI6YHWfMpl7JQDWl1xiUT1cX2icF =UqmB -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
