Re: WIP patch (v2) for updatable security barrier views - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: WIP patch (v2) for updatable security barrier views
Date
Msg-id CA+U5nMJ_MirGivpB45uyY+pR8SqSzz6itniN8oayaYwt3RRrqA@mail.gmail.com
Whole thread Raw
In response to Re: WIP patch (v2) for updatable security barrier views  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-hackers
On 30 January 2014 11:55, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:

> Hmm, looks like this is a pre-existing bug.
>
> The first thing I tried was to reproduce it using SQL, so I used a
> RULE to turn a DELETE into a SELECT FOR UPDATE. This is pretty dumb,
> but it shows the problem:
>
> CREATE TABLE foo (a int);
> CREATE RULE foo_del_rule AS ON DELETE TO foo
>   DO INSTEAD SELECT * FROM foo FOR UPDATE;
> DELETE FROM foo;
>
> ERROR:  no relation entry for relid 1
>
> So I think this should be fixed independently of the updatable s.b. view code.

Looks to me there isn't much use case for turning DML into a SELECT -
where would we expect the output to go to if the caller wasn't
prepared to handle the result rows?

IMHO we should simply prohibit such cases rather than attempt to fix
the fact they don't work. We know for certain nobody relies on this
behaviour because its broken already.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Add CREATE support to event triggers
Next
From: Stephen Frost
Date:
Subject: Re: Prohibit row-security + inheritance in 9.4?