2011/7/8 Heikki Linnakangas <heikki.linnakan...@enterprisedb.com>: > 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. > I might misread his description at first. Hmm. If we introduce DBA the scenario and the condition to push down qualifiers, it may be possible to explain more simply.
A challenge of this approach is to determine what qualifier shall be used to index accesses in the stage of distribute_qual_to_rels(); prior to the optimizer's selection of access methods. Do you have any good idea, or suggestion? Thanks, -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
