2010/6/1 KaiGai Kohei <kai...@ak.jp.nec.com>: >> Eh, if that's the consensus, it doesn't bother me that much, but it >> doesn't really answer the question, either: supposing we add an >> explicit concept of a security view, what should its semantics be? > > How about a GUC option to provide the default, like default_with_oids?
Bad idea. We already have enough problems with GUCs that can create security problems if they're unexpectedly set to the wrong value. We don't need any more. Anyhow, that's trivia. The real thing we need to decide here is to design the security mechanism. We can change the syntax to whatever we want very easily. Here's another thought. If we're leaning toward explicit syntax to designate security views (and I do mean IF, since only one person has signed on to that, even if it is Tom Lane!), then maybe we should think about ripping out the logic that causes regular views to be evaluated using the credentials of the view owner rather than the person selecting from it. A security view would still use that logic, plus whatever additional stuff we come up with to prevent leakage. Perhaps this would be viewed as a nasty backward compatibility break, but the upside is that we'd then be being absolutely clear that a non-security view isn't and can never be trusted to be a security barrier. Right now we're shipping something that purports to act as a barrier but really doesn't. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers