On Wed, Jul 20, 2011 at 09:02:59AM +0200, Yeb Havinga wrote: > On 2011-07-09 09:14, Kohei KaiGai wrote: >> OK, I'll try to modify the patch according to the flag of pg_proc design. >> As long as the default of user-defined function is off, and we provide >> built-in functions >> with appropriate configurations, it seems to me the burden of DBA is >> quite limited. > > A different solution to the leaky view problem could be to check access > to a tuple at or near the heaptuple visibility level, in addition to > adding tuple access filter conditions to the query. This would have both > the possible performance benefits of the query rewriting solution, as > the everything is filtered before further processing at the heaptuple > visibility level. Fixing leaky views is not needed because they don't > exist in this case, the code is straightforward, and there's less change > of future security bugs by either misconfiguration of leakproof > functions or code that might introduce another leak path.
The SQL-level semantics of the view define the access rules in question. How would you translate that into tests to apply at a lower level? -- Noah Misch http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
