From: | Josh Kupershmidt <schmiddy(at)gmail(dot)com> |
---|---|
To: | "Gauthier, Dave" <dave(dot)gauthier(at)intel(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: privs drop after alter table |
Date: | 2012-05-03 18:54:07 |
Message-ID: | CAK3UJRFFh2Ebcbf2F=KgwLFArwHHOmWhmyEyqnAe0Gmup+yeig@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, May 3, 2012 at 11:14 AM, Gauthier, Dave <dave(dot)gauthier(at)intel(dot)com> wrote:
> v8.3.4 on linux
> After this..
>
> alter table fred alter column wilma set default 'dino';
>
> ...it appeared that a user that had insert,delete,update privs lost them.
>
> I regranded and things went back to normal.
>
> Is it correct for those privs to be dropped in this case? If so, why (just
> curious).
I don't think the behavior you described would be correct. But works
for me on 8.3.18 (see testcase below), and I don't see any bugfixes
like this in the 8.3.x release notes. Are you able to produce a
self-contained test case?
Josh
-- These commands were run as user 'josh'
test=# CREATE TABLE fred (wilma text);
CREATE TABLE
test=# GRANT INSERT, DELETE, UPDATE ON fred TO dummy;
GRANT
test=# \z fred
Access privileges for database "test"
Schema | Name | Type | Access privileges
--------+------+-------+-----------------------------------
public | fred | table | {josh=arwdxt/josh,dummy=awd/josh}
(1 row)
test=# ALTER TABLE fred ALTER COLUMN wilma SET DEFAULT 'dino';
ALTER TABLE
test=# \z fred
Access privileges for database "test"
Schema | Name | Type | Access privileges
--------+------+-------+-----------------------------------
public | fred | table | {josh=arwdxt/josh,dummy=awd/josh}
(1 row)
From | Date | Subject | |
---|---|---|---|
Next Message | EllyR | 2012-05-03 18:55:47 | Move the postgreSQL database from Drive C to Map Network Drive (Called Z) |
Previous Message | Michael Nolan | 2012-05-03 18:25:15 | Re: Issue with rsync based incremental backup : postgres: startup process waiting for 0000000100000001000000D2 |