Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE
От | Karel Zak - Zakkr |
---|---|
Тема | Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE |
Дата | |
Msg-id | Pine.LNX.3.96.1000301161406.6297D-100000@ara.zf.jcu.cz обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE (Peter Eisentraut <e99re41@DoCS.UU.SE>) |
Ответы |
Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE
|
Список | pgsql-hackers |
> 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). Yes. Just today I look at Oracle's documentation for ROLEs, PROFILEs ... my idea is prepare acl/account code for this freatures too. What? IMHO this discussion good adept for any new-acl&accout project. Agree? > By the way: Regarding your original patch that disallowed LOCK to users, I ... and I see your web page, you listen good music :-) > 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? You mean this original PG's code (?): if (lockstmt->mode == AccessShareLock) aclresult = pg_aclcheck(lockstmt->relname, GetPgUserName(), ACL else aclresult = pg_aclcheck(lockstmt->relname, GetPgUserName(), ACL if (aclresult != ACLCHECK_OK) elog(ERROR, "LOCK TABLE: permission denied"); Yes. The my patch create a lock-permission level over this current code. It is global setting and example for all non-AccessShareLocks you must have pg_shadow->locktable privilege and 'write' privilage for table. It is because I have users which needs update/insert access to tables, but I not want allow a lock command for these users. Karel
В списке pgsql-hackers по дате отправления: