On Tue, Aug 30, 2016 at 3:05 AM, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > On 28 August 2016 at 21:23, Joe Conway <m...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
