| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Bug: RLS policy FOR SELECT is used to check new rows |
| Date: | 2023-10-24 15:59:06 |
| Message-ID: | 572918.1698163146@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> On Tue, 24 Oct 2023 at 09:36, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
>> I'd say that this error is wrong. The FOR SELECT policy should be applied
>> to the WHERE condition, but certainly not to check new rows.
> Yes, I had the same thought recently. I would say that the SELECT
> policies should only be used to check new rows if the UPDATE has a
> RETURNING clause and SELECT permissions are required on the target
> relation.
> In other words, it should be OK to UPDATE a row to new values that are
> not visible according to the table's SELECT policies, provided that
> the UPDATE command does not attempt to return those new values. That
> would be consistent with what we do for INSERT.
> Note, that the current behaviour goes back a long way, though it's not
> quite clear whether this was intentional [1].
I'm fairly sure that it was intentional, but I don't recall the
reasoning; perhaps Stephen does. In any case, I grasp your point
that maybe we should distinguish RETURNING from not-RETURNING cases.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jelte Fennema | 2023-10-24 16:03:48 | Add new for_each macros for iterating over a List that do not require ListCell pointer |
| Previous Message | Tom Lane | 2023-10-24 15:42:15 | Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges |