On 08.07.2011 11:03, Kohei KaiGai wrote:
2011/7/7 Noah Misch<n...@2ndquadrant.com>:
Making a distinction based simply on the call being an operator vs. a function
is a dead end. I see these options:
1. The user defining a security view can be assumed to trust the operator class
members of indexes defined on the tables he references. Keep track of which
those are and treat only them as non-leakable. This covers many interesting
cases, but it's probably tricky to implement and/or costly at runtime.
It requires DBA massive amount of detailed knowledge about functions underlying
operators used in a view. I don't think it is a realistic assumption.
2. Add a pg_proc flag indicating whether the function is known leak-free.
Simple, but tedious and perhaps error-prone.
+1
IMHO the situation from DBA's point of view is exactly opposite. Option
two requires deep knowledge of this leaky views issue. The DBA needs to
inspect any function he wants to mark as leak-free closely, and
understand that innocent-looking things like casts can cause leaks. That
is not feasible in practice. Option 1, however, requires no such
knowledge. Operators used in indexes are already expected to not throw
errors, or you would get errors when inserting certain values to the
table, for example.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
