On Mon, Sep 26, 2011 at 9:51 AM, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: >> No, you're missing my point completely. If we use a flexible options >> syntax here, then we have to decide on what behavior CREATE OR REPLACE >> should have for all future options, without knowing what they are yet, >> or what behavior will be appropriate. >> > Hmm. Indeed, it seems to me fair enough reason. > > In this syntax case, the only way to clear the security_barrier flag > is to drop view > once, then create a view, isn't it?
I was imagining we'd have ALTER VIEW .. [NO] SECURITY or something like that. > And, is the security_barrier flag still stored within reloptions field? No. That would be missing the point. But keep in mind no one else has endorsed my reasoning on this one as yet... -- 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
