Dear Tom,
> > (2) Although I subscribe your first 3 points, I do not like the 4th point.
>
> I didn't either. After working on it some more, what I want to do now
> is keep the ACL representation the same as it is, but implicitly assume
> that the owner has all grant options whether the ACL says
Fabien COELHO <[EMAIL PROTECTED]> writes:
>> 4. I think that the system ACL entry should be "hidden" and not
>> displayed by ACL-list printing. I'm not quite sure yet how to make
>> that happen. It would be nicer if the owner ID could be passed to
>> recursive_revoke out-of-band, instead of being
I wrote:
> I think the correct solution involves having recursive_revoke look to
> see if D still has the rights from somewhere else before it goes off to
> recursively revoke D's grants. This makes it correctly implement the
> notion that one always has the union of the rights granted by anyone.
Christopher Kings-Lynne wrote:
> Guess this means I have to tweak my ACL parser in phpPgAdmin. If you
> could do something to make that less of a NIGHTMARE, i'd be all ears
Check out how the information schema views relating to privileges are
implemented. There are some undocumented accessor fu
Dear Tom,
> 4. I think that the system ACL entry should be "hidden" and not
> displayed by ACL-list printing. I'm not quite sure yet how to make
> that happen. It would be nicer if the owner ID could be passed to
> recursive_revoke out-of-band, instead of being represented inside the
> ACL list,
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Basically our whole API of communicating ACL information to the user is
> poor. Look at psql \z:
Well, if you don't like that, there's always the spec's way:
regression=> select * from information_schema.table_privileges where table_name =
'mytable';
Basically our whole API of communicating ACL information to the user is
poor. Look at psql \z:
test=> create table test(x int);
CREATE TABLE
test=> grant all on test to public;
GRANT
test=> \z test
Access privileges for database
I wrote:
> I've been thinking more about this, and realizing that there are more
> implications than I first thought. Specifically, we have to consider
> how any hacking we do here will affect recursive_revoke().
After further consideration I think that at least part of the problem
here is that r
> Guess this means I have to tweak my ACL parser in phpPgAdmin. If you
> could do something to make that less of a NIGHTMARE, i'd be all ears :P
>
> 1. Make it easy to convert an array to a rowset
> 2. Fabien's accessor functions? Would they help?
Sure. I needed these functions to convert acl ar
I wrote:
> If you like that, I have a further suggestion, which is to not include
> the owner's grant options in the default ACL, either.
I've been thinking more about this, and realizing that there are more
implications than I first thought. Specifically, we have to consider
how any hacking we d
Schema | Name | Type |Access privileges
+-+---+--
public | mytable | table | {miriam=a*r*w*d*R*x*t*/miriam,=r/miriam}
Changing the default ACL would take this down to
public | mytable | table | {miriam=arwdRxt/miriam,=r
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think the printout format is fine and the silent non-removal of
>> grant options was a bad idea, particularly since it doesn't seem to
>> be saving any code (GRANT/REVOKE check ownerness anyway). I propose
>> that we take out the
Tom Lane wrote:
> I think the printout format is fine and the silent non-removal of
> grant options was a bad idea, particularly since it doesn't seem to
> be saving any code (GRANT/REVOKE check ownerness anyway). I propose
> that we take out the special cases in merge_acl_with_grant that
> prohib
Deepak Bhole of Red Hat asked me about the following situation:
regression=# create table test (f1 int);
CREATE TABLE
regression=# revoke insert,update,delete,references on test from postgres;
REVOKE
regression=# \z test
Access privileges for database "regression"
Schema | Name | Type |
14 matches
Mail list logo
