On Sat, Sep 24, 2011 at 5:37 PM, Noah Misch <noah@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 <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.
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