Greg Smith wrote:
Where I suspect this is all is going to settle down into is that if 1) the SE GUC is on and 2) one of the tables in a join has rows filtered, then you can expect that a) it's possible that the result will leak information, which certainly need to be documented, and b) the optimizations Tom mentioned that "assume foreign key constraints hold" will not be possible to implement, so performance will suck compared to a similar situation in an unsecured environment.
c) security feature gives the optimizer a hint "don't optimize out this table, please!" via a security hook. I think it is a quite reasonable approach, as I noted in another message. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
