Re: privs drop after alter table

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)

In response to

Browse pgsql-general by date

  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