| From: Jim Starkey <jas@...>
| >Geoff Worboys wrote:
| >I am following so far, but...
| >
| >>Real applications must connect to a database in order the
| >>authenticate a client. There are privileges that belong to
| >>the application, and different privileges that belong to the
| >>client. An application should be able to control database
| >>access based on what it knows of the client. This requires
| >>multiple roles and the ability to activate/deactivate
| >>specific roles.

| The second part of the puzzle is row level access control. There are
| very few application that give client unrestricted read access to tables
| within a database. Netfrasite controls access to most tables on a
| per-row basis using "filtersets". A filterset is a named list of
| <table-name, boolean-expression> pairs. An application can activate or
| deactivate filtersets at will. When compiling any table reference, the
| SQL compiler checks all active filtersets for references to that table.
| The boolean expression supplied is "and"ed to the SQL boolean (the
| algorithm is applied recursively, so any table referenced in a subquery
| within a filterset boolean has any active filterset applied to it as
| well). From the application's perspective, rows that fail a filter
| expression don't exist (exception: primary an unique keys are still
| enforced).

Jim's profecy:

GRANT <SELECT | INSERT | UPDATE | DELETE | ALL> ON <table> TO <rolename>
WHERE <search_condition>