| From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
|---|---|
| To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Bug: RLS policy FOR SELECT is used to check new rows |
| Date: | 2023-11-09 15:59:20 |
| Message-ID: | CAEZATCVthTfNb8EaLiE=bJkn1yGiNx0m_ntLd2P39BHWD0UP3g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 9 Nov 2023 at 15:16, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> 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 fetching from a table and for new rows after
> an UPDATE?
>
> The attached patch does that. What so you think?
>
So you'd be able to write policies that allowed you to do an
INSERT/UPDATE ... RETURNING, where the WITH CHECK part of the SELECT
policy allowed you see the new row, but then if you tried to SELECT it
later, the USING part of the policy might say no.
That seems pretty confusing. I would expect a row to either be visible
or not, consistently across all commands.
Regards,
Dean
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2023-11-09 16:08:51 | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |
| Previous Message | Drouvot, Bertrand | 2023-11-09 15:45:57 | Re: Synchronizing slots from primary to standby |