security barrier INSERT

From: Drew Crawford <drew(at)sealedabstract(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: security barrier INSERT
Date: 2014-10-25 02:05:19
Message-ID: 81199C5A-CF37-4D01-A1C7-D62E4FA375EF@sealedabstract.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi guys, I’m seeing some non-intuitive behavior with the new updateable security barrier views in 9.4. Below is the behavior of 9.4b3:

> =# create table widget ( id integer);
> CREATE TABLE
> =# create view widget_sb WITH (security_barrier=true) AS SELECT * from widget where id = 22;
> CREATE VIEW
> =# insert into widget_sb (id) values (23);
> INSERT 0 1
> =# select * from widget;
> id
> ----
> 23
> (1 row)

I think the insert should fail, since the view can only contain widgets with id = 22, and the widget being inserted has id 23. In reality, the insert to the behind table succeeds as shown above, although it still remains absent from the view:

> =# select * from widget_sb;
> id
> ----
> (0 rows)

IMHO this is nonintuitive, the intuitive behavior of a security_barrier view should be to forbid inserting rows that can’t appear in the view.

Have I missed something fundamental here?

Drew

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brightwell, Adam 2014-10-25 02:26:23 Re: security barrier INSERT
Previous Message Tom Lane 2014-10-25 01:28:25 Re: Comment in outfunc.c