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.
pgpFge1bfLlD6.pgp
Description: PGP signature
