On Mon, 2023-11-13 at 12:57 -0500, Robert Haas wrote:
> On Fri, Nov 10, 2023 at 7:43 AM Laurenz Albe wrote:
> > So, from my perspective, we should never have let FOR SELECT policies
> > mess with an UPDATE. But I am too late for that; such a change would
> > be way too invasive now. So I'd like
On Fri, Nov 10, 2023 at 7:43 AM Laurenz Albe wrote:
> So, from my perspective, we should never have let FOR SELECT policies
> mess with an UPDATE. But I am too late for that; such a change would
> be way too invasive now. So I'd like to introduce a "back door" by
> creating a FOR SELECT policy w
On Fri, 2023-11-10 at 09:39 +, Dean Rasheed wrote:
> On Thu, 9 Nov 2023 at 18:55, Laurenz Albe wrote:
> > I think it can be useful to allow a user an UPDATE where the result
> > does not satisfy the USING clause of the FOR SELECT policy.
> >
> > The idea that an UPDATE should only produce row
On Thu, 9 Nov 2023 at 18:55, Laurenz Albe wrote:
>
> I think it can be useful to allow a user an UPDATE where the result
> does not satisfy the USING clause of the FOR SELECT policy.
>
> The idea that an UPDATE should only produce rows you can SELECT is not
> true today: if you run an UPDATE witho
On Thu, 2023-11-09 at 15:59 +, Dean Rasheed wrote:
> On Thu, 9 Nov 2023 at 15:16, Laurenz Albe wrote:
> > I have thought some more about this, and I believe that if FOR SELECT
> > policies are used to check new rows, you should be allowed to specify
> > WITH CHECK on FOR SELECT policies. Why
On Thu, 9 Nov 2023 at 15:16, Laurenz Albe wrote:
>
> I have thought some more about this, and I believe that if FOR SELECT
> policies are used to check new rows, you should be allowed to specify
> WITH CHECK on FOR SELECT policies. Why not allow a user to specify
> different conditions for fetchi
On Wed, 2023-10-25 at 09:45 +0200, Laurenz Albe wrote:
> I can accept that the error is intentional, even though it violated the
> POLA for me. I can buy into the argument that an UPDATE should not make
> a row seem to vanish.
>
> I cannot buy into the constraint argument. If the table owner wan
On Tue, 2023-10-24 at 15:05 -0400, Stephen Frost wrote:
> On Tue, Oct 24, 2023 at 14:42 Robert Haas wrote:
> > On Tue, Oct 24, 2023 at 1:46 PM Jeff Davis wrote:
> > > Perhaps the idea is that if there are constraints involved, the failure
> > > or success of an INSERT/UPDATE/DELETE could leak inf
Greetings,
On Tue, Oct 24, 2023 at 14:42 Robert Haas wrote:
> On Tue, Oct 24, 2023 at 1:46 PM Jeff Davis wrote:
> > Perhaps the idea is that if there are constraints involved, the failure
> > or success of an INSERT/UPDATE/DELETE could leak information that you
> > don't have privileges to read
On Tue, Oct 24, 2023 at 1:46 PM Jeff Davis wrote:
> Perhaps the idea is that if there are constraints involved, the failure
> or success of an INSERT/UPDATE/DELETE could leak information that you
> don't have privileges to read.
My recollection of this topic is pretty hazy, but like Tom, I seem t
On Tue, 2023-10-24 at 11:59 -0400, Tom Lane wrote:
> 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.
Perhaps the idea is that if there are cons
Dean Rasheed writes:
> On Tue, 24 Oct 2023 at 09:36, Laurenz Albe 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 sh
On Tue, 24 Oct 2023 at 09:36, Laurenz Albe 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
13 matches
Mail list logo
