Robert Haas 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.
Without commenting on the usefulness of blind deletes...
How about returning a placeholder row but with all the values replaced with
NULL?
In the absence of returning does the delete count show the total number of
rows deleted or only the number of rows deleted that the user would be aware
of if they issued a select with the same criteria? Whatever the answer the
number of rows returned with returning should match the row count normally
noted.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/CREATE-POLICY-and-RETURNING-tp5823192p5823374.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.