Re: CREATE POLICY and RETURNING

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CREATE POLICY and RETURNING
Date: 2014-10-17 11:12:18
Message-ID: CAHGQGwHAA_zMqirsMbGW_etxBRXJUnk6yYN1oNjMVGq0uzx6=w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 17, 2014 at 3:49 AM, Robert Haas <robertmhaas(at)gmail(dot)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

Attachment Content-Type Size
fix_update_policy_and_pg_dump_bug.patch text/x-patch 518 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2014-10-17 11:39:52 Re: [PATCH] add ssl_protocols configuration option
Previous Message Pavel Stehule 2014-10-17 11:12:05 Re: proposal: plpgsql - Assert statement