Re: intentional or oversight? pg_dump -c does not restore default priviliges on schema public

From: Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl>
To: pgsql-general(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Subject: Re: intentional or oversight? pg_dump -c does not restore default priviliges on schema public
Date: 2017-02-13 08:09:06
Message-ID: 23252987.YLsmlhlehZ@techfox
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi Tom/Stephen/Adrian,

Op zaterdag 11 februari 2017 15:28:55 schreef Tom Lane:
> I'm inclined to argue that it was a mistake to include any non-pinned
> objects in pg_init_privs.
<cut>
> We might need to fix pg_dump too, but I think these entries in
> pg_init_privs should simply not be there.

Thanks for picking this up, I'll probably see this subject pop up on hackers
and/or committers at some point ;)

Allow me to emphasize that this issue basically means that for v9.6 after
restoring a dump created with the '-c' option one ends up in a situation that
might be quite confusing for users that didn't have to pay much attention yet
to handling priviliges... i.e. trying even a plain select on table_a in the
public schema as a non-system user returns something like:
ERROR: relation "table_a" does not exist

--

Best,

Frank.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Chris Travers 2017-02-13 09:36:48 Recorded PostgreSQL at 10TB and Beyond
Previous Message Steve Atkins 2017-02-13 03:42:56 Re: 64 and 32 bit libpq