On Sat, Sep 24, 2011 at 5:37 PM, Noah Misch <n...@leadboat.com> wrote: > On Fri, Sep 23, 2011 at 06:25:01PM -0400, Robert Haas wrote: >> On Mon, Sep 12, 2011 at 3:31 PM, Kohei KaiGai <kai...@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.
Hmm, you might be right, although I'm not sure we've been 100% consistent about that, since we previously made CREATE OR REPLACE LANGUAGE not replace the owner with the current user. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
