On Fri, Oct 17, 2014 at 3:49 AM, Robert Haas <robertmh...@gmail.com> wrote: >>> That's an argument in favour of only applying a read-filtering policy >>> where a RETURNING clause is present, but that introduces the "surprise! >>> the effects of your DELETE changed based on an unrelated clause!" issue. >> >> No- if we were going to do this, I wouldn't want to change the existing >> structure but rather provide either: >> >> a) a way to simply disable RETURNING if the policy is in effect and the >> policy creator doesn't wish to allow it >> b) allow the user to define another clause which would be applied to the >> rows in the RETURNING set > > I think you could probably make the DELETE policy control what can get > deleted, but then have the SELECT policy further filter what gets > returned.
+1 That's more intuitive to me because another security feature "privilege" works in that way, i.e., SELECT privilege not DELETE controls RETURNING. Another minor problem that I found is that pg_dump always fails when there is a row-level policy for update. I think that the attached patch should be applied. Regards, -- Fujii Masao
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c index c56a4cb..16ebc12 100644 --- a/src/bin/pg_dump/pg_dump.c +++ b/src/bin/pg_dump/pg_dump.c @@ -2939,7 +2939,7 @@ dumpRowSecurity(Archive *fout, DumpOptions *dopt, RowSecurityInfo *rsinfo) cmd = "SELECT"; else if (strcmp(rsinfo->rseccmd, "a") == 0) cmd = "INSERT"; - else if (strcmp(rsinfo->rseccmd, "u") == 0) + else if (strcmp(rsinfo->rseccmd, "w") == 0) cmd = "UPDATE"; else if (strcmp(rsinfo->rseccmd, "d") == 0) cmd = "DELETE";
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
