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: | Raw Message | Whole Thread | 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 |