Re: BUG #14456: pg_dump doesn't restore permissions on tables belonging to an extension

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Moshe Jacobson <moshe(at)neadwerx(dot)com>, daniele(dot)varrazzo(at)gmail(dot)com, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #14456: pg_dump doesn't restore permissions on tables belonging to an extension
Date: 2017-01-30 04:30:48
Message-ID: 20170130043048.GU9812@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-bugs

All,

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> >> Hmm. There's an argument to be made that ALTER EXTENSION ADD should
> >> absorb whatever the object's current ACLs are into the pg_init_privs
> >> entries for the extension. (I don't think it does that now, though
> >> I might be wrong.) However ...
>
> > I've not gone and looked yet, but I doubt that it does. I think I can
> > agree with the argument that it really should add those ACLs to
> > pg_init_privs. Of course, any furhter manipulation of the ACLs from
> > that point will cause those ACLs to be included in the pg_dump.
>
> > I'll take a look at ALTER EXTENSION ADD and pg_init_privs.
>
> By the same token, does ALTER EXTENSION DROP remove those entries?

I've pushed a fix for this and back-patched it to 9.6.

Thanks!

Stephen

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2017-02-01 07:41:38 Re: [HACKERS] Bug in Physical Replication Slots (at least 9.5)?
Previous Message sellier nicolas 2017-01-27 14:16:04