Re: WIP patch (v2) for updatable security barrier views

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: WIP patch (v2) for updatable security barrier views
Date: 2014-01-30 14:22:47
Message-ID: CA+U5nMJ_MirGivpB45uyY+pR8SqSzz6itniN8oayaYwt3RRrqA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 30 January 2014 11:55, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2014-01-30 14:41:28 Re: Prohibit row-security + inheritance in 9.4?
Previous Message Dimitri Fontaine 2014-01-30 13:53:35 Re: Add CREATE support to event triggers