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.
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 |