Re: [gnome-db] Oracle, Table Names and Progress



On 08 Feb 2003 18:24:44 +0100
Rodrigo Moya <rodrigo gnome-db org> wrote:

> On Sat, 2003-02-08 at 14:30, Steve Fosdick wrote:
> > > -> for every object, a list of flags describing what the user
> > > which is   connected can do on the objects (select, ...)
> > 
> > Have you thought what flags?  We want to be sure to cover all the
> > bases. The ones that spring to mind are: SELECT, UPDATE, INSERT,
> > DELETE, ALTER, DROP.
> > 
> I guess this would be better done via the GRANT/REVOKE API we have
> talked about (http://bugzilla.gnome.org/show_bug.cgi?id=82679).
> Another to call to retrive the permissions for any object should be
> added, apart from the GRANT/REVOKE calls in each provider.

I looked at the buglist entry you refer to.

Does anyone know of any databases with permission checking any more
precise than table-level?  If not then we should be able to implement a
get_permissions call fairly easily which takes the name of the object -
if the underlying database only does permission checking at user/schema
level it can just ignore the name of the object and return the same
permissions for everything.

We would also need a way to discover whether the current user is able to
create new objects.  Oracle checks the permission separately for each
type of object, TABLE, VIEW, SYNONYM etc, so we would need to specify
the object type in that call or have the call return a list or bitmap of
what the user can create.  Does anyone know of a database that requires
us to be more specific than that?

Having the application check for permission using the extra call would
obviously be extra work for the application.  It may save execution time
though if the application doesn't routinely check the permission of
every table but only checks before letting the user do something that
requires the permission concerned.  If the application is going to step
through every table though and fetch this information it would probably
be faster to have it returned by the GDA_CONNECTION_SCHEMA_TABLES call
as originally proposed.

Steve.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]