On Sat, 26 Sept 2026 at 15:10, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>
> On Fri, 25 Sept 2026 at 14:52, Viktor Holmberg <v@viktorh.net> wrote:
> >
> > On 25 Sep 2026 at 12:48 +0200, Kirill Reshke <reshkekirill@gmail.com>, wrote:
> >
> > On Fri, 25 Sept 2026 at 09:45, shihao zhong <zhong950419@gmail.com> wrote:
> >
> > In 19, a user with only INSERT and SELECT on a security_barrier view can
> > read rows that the view hides, with ON CONFLICT DO SELECT. Before 19 that
> > user had no way to reach a hidden row, because DO UPDATE needs UPDATE.
> >
> > I see two ways to go. Keep the behavior and say it plainly in the
> > security_barrier docs. Or check the existing row against the
> > view's quals in DO SELECT, the same way RLS does, and raise an error when
> > the row is hidden. I have a draft patch for the second, for views with a
> > check option.
> >
> > Which way do people prefer? If it is the second, should it be a 19 open
> > item?
> >
> > Well spotted Shihao. I agree with Kirill that this has to be fixed before release, a doc fix is not enough.
> > Please share your patch Shihao. I should be able to review within a week.
> >
>
> Given the timing, I think we should just reject INSERT ... ON CONFLICT
> DO SELECT on a security-barrier view with a "feature not supported"
> error.
>
> That particular combination of features is probably not that common,
> so it doesn't detract too much from the utility of ON CONFLICT DO
> SELECT, and that will give more time to consider the issue properly
> for v20, if we want.
>
> Regards,
> Dean
I think this patch works for sec barrier views.
But also, looks like with INSERT ON CONFLICT SELECT user now (with and
without v1 patch) access data it would otherwise unable to:
```
reshke=# create view vhs AS select * from t where i = 2;
CREATE VIEW
reshke=# grant select, insert on vhs to intruder ;
GRANT
reshke=# set role intruder ;
SET
reshke=> table t;
ERROR: permission denied for table t
reshke=> insert into vhs values(1) on conflict(i) do select returning *;
i
---
1
(1 row)
INSERT 0 1
```
So, on pg < 19 there is no way to retrieve i = 1 row from relation,
and with pg19 there is a way. Not sure if we should guarantee
something for non-sec-barrier views.
Is that an issue?
--
Best regards,
Kirill Reshke
