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
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 |