Re: [v9.2] Fix Leaky View Problem - Mailing list pgsql-hackers

From Noah Misch
Subject Re: [v9.2] Fix Leaky View Problem
Date
Msg-id 20110924213752.GB6698@tornado.leadboat.com
Whole thread Raw
In response to Re: [v9.2] Fix Leaky View Problem  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [v9.2] Fix Leaky View Problem
List pgsql-hackers
On Fri, Sep 23, 2011 at 06:25:01PM -0400, Robert Haas wrote:
> On Mon, Sep 12, 2011 at 3:31 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
> > The Part-1 implements corresponding SQL syntax stuffs which are
> > "security_barrier"
> > reloption of views, and "LEAKPROOF" option on creation of functions to be stored
> > new pg_proc.proleakproof field.
>
> The way you have this implemented, we just blow away all view options
> whenever we do CREATE OR REPLACE VIEW.  Is that the behavior we want?
> If a security_barrier view gets accidentally turned into a
> non-security_barrier view, doesn't that create a security_hole?

I think CREATE OR REPLACE needs to keep meaning just that, never becoming
"replace some characteristics, merge others".  The consequence is less than
delightful here, but I don't have an idea that avoids this problem without
running afoul of some previously-raised design constraint.

pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: WIP: SP-GiST, Space-Partitioned GiST
Next
From: Daniel Farina
Date:
Subject: Re: Hot Backup with rsync fails at pg_clog if under load