From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | Joe Conway <mail(at)joeconway(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RLS related docs |
Date: | 2016-09-15 18:32:32 |
Message-ID: | CA+TgmoYjdWmfOkKtVt5Qyg_7Aw+h8erxiwsWuYYJXM2fyOUEBg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 30, 2016 at 3:05 AM, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
> On 28 August 2016 at 21:23, Joe Conway <mail(at)joeconway(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-09-15 18:33:31 | Re: RLS related docs |
Previous Message | Andrew Borodin | 2016-09-15 18:14:18 | Re: GiST: interpretation of NaN from penalty function |