On Tue, Aug 30, 2016 at 3:05 AM, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
> On 28 August 2016 at 21:23, Joe Conway <mail@joeconway.com> wrote:
>> Apologies for the delay, but new patch attached. Assuming no more
>> comments, will commit this, backpatched to 9.5, in a day or two.
>
> Looking at this again, I think there is something fishy about these
> dump/restore flags.
>
> If you do pg_dump --enable-row-security, then row_security is turned
> on during the dump and only the user-visible portions of the tables
> are dumped. But why does such a dump emit "SET row_security = on;" as
> part of the dump? There doesn't appear to be any reason for having
> row_security turned on during the restore just because it was on
> during the dump. The INSERT policies may well be different from the
> SELECT policies, and so this may lead to a dump that cannot be
> restored. ISTM that row_security should be off inside the dump, and
> only enabled during restore if the user explicitly asks for it,
> regardless of what setting was used to produce the dump.
I think you are right about this.
> Also, isn't it the case that --enable-row-security during pg_restore
> is only relevant when performing a data-only restore (like
> --disable-triggers). Otherwise, it looks to me as though the restore
> will create the tables, restore the data, and then only at the end
> restore the table policies and enable row level security on the
> tables. So it looks like the flag would have no effect (and a
> COPY-format dump would work fine) for a non-data-only dump.
Hmm. That seems odd.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
