Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE

On Wed, 1 Mar 2000, Karel Zak - Zakkr wrote:

> Example 
> 
>  reloid  | user_insert | group_insert |
>  --------------------------------------
>  12345   | "1111,2222" | "545454"     |
> 
>  .. parse these strings a easy and 'Does Peter have access to x?' is realy
> simple.

> >    privilege char, -- maybe 'U' update, 'I' insert, etc.
> 
>  I really not sure if is good still create this monolithic string,
> why not use one (bool) column for update one for insert ..etc?
> It is fastly and easy (a string needs parse, etc).

Space. A char column takes one byte (when using the internal char1 type),
five or six bool columns take five or six bytes plus all the overhead.
Also you get into the problem where certain flag combinations are not even
valid.

> Yes, a speed will problem, it must be cached (in an separate acl cache?),
> or after (connection) start create a temp table with acl for a current user 
> and with relevant information only.

Steal the code on how triggers are looked up. It does an index scan. This
table will be huge (on average probably O(#tables * #users)) but it has
the advantage that it is a direct mapping from what SQL calls a "privilege
descriptor", so implementation could be easier.

I would like to take a look at SQL3 first, because they define some more
privilege stuff which we could take into account (ROLES, for example).


By the way: Regarding your original patch that disallowed LOCK to users, I
looked it up in the source and it turns out that in order to lock a table
you need write access to it. Isn't that sufficient?


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden