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. 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. I never really looked at the RLS dump/restore code. Am I missing something? Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
