On Wed, 1 Mar 2000, Karel Zak - Zakkr wrote:
> Yes. Just today I look at Oracle's documentation for ROLEs, PROFILEs
> ... my idea is prepare acl/account code for this freatures too. What?
I read about that in SQL3 yesterday and I think we could transparently
adapt the current group scheme to it.
> > 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?
> 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.
Why?
You are saying to these users, "You can write data to these tables but I
can't guarantee you that anything you do will actually be written,
consistent, and non-corrupted." And as I said before, this doesn't prevent
users from actually *locking* tables either, because there are several
other methods to do that.
One thing I thought about is that you might want to reserve exclusive
locks and access exclusive locks, and possibily ShareRowExclusiveLock
(that name makes a lot of sense to me, btw.) and ShareLock to table owners
and superusers. That way vanilla users with write access can only do a
RowExclusiveLock at best. Perhaps there could be a grant fancylock on
table command (kind of :), but that would have to be reviewed closely.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
