Skip site navigation (1) Skip section navigation (2)


From: Karel Zak - Zakkr <zakkr(at)zf(dot)jcu(dot)cz>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Date: 2000-03-01 10:14:12
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, 29 Feb 2000, Peter Eisentraut wrote:

> On Tue, 29 Feb 2000, Karel Zak - Zakkr wrote:
> > My acl idea:
> > reloid  | user_insert        | group_insert | user_delete ..........etc
> > ---------------------------------------------------------
> > 12345   | {"karel", "peter"} | {"group1"}   | {"karel"}   ..........etc
> This still has arrays. (shudder) Try getting the information 'Does Peter
> have access to x?' out of that. I was thinking along the lines of

 As I say: we can use oid or string with oids instead array.


 reloid  | user_insert | group_insert |
 12345   | "1111,2222" | "545454"     |

 .. parse these strings a easy and 'Does Peter have access to x?' is realy

> create table pg_privilege/pg_acl/? (
>    objoid oid, -- not only reloid, but types, functions, etc.
			yes, yes, yes ! (the oracle allow grant priv. to
				25(!) different features)

>    userid int,

 If I understend you, you want save to one line information about one
user only (?), if yes this table will huge (sum(object) * sum(users)),
but probably fastly (because it not needs parse any array or string).
Hmm, perhaps it is not bad idea. What say the other?

>    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).

>    grant_option bool
> )

 It is goods if you agree with separate acl table :-)
> To be extended to cover column access as well. (Might have to be yet
> another table.) Mathematically, this will be slower (especially since you
> can't use SysCache on composite keys(???)) but similar schemas are
> employed throughout by triggers etc.

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.

In response to


pgsql-hackers by date

Next:From: Karel Zak - ZakkrDate: 2000-03-01 10:38:08
Subject: RE: [HACKERS] Bug report for 7.0beta1 in 'CREATE FUNCTION...'
Previous:From: Moray McConnachieDate: 2000-03-01 09:48:18
Subject: Re: [HACKERS] Re: [SQL] prob with aggregate and group by - returns multiplesh

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group