2012/12/7 Simon Riggs <si...@2ndquadrant.com>: > On 5 December 2012 11:16, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: > >>> Oracle defaults to putting VPD on all event types: INSERT, UPDATE, >>> DELETE, SELECT. ISTM we should be doing the same, not just say "we can >>> add an INSERT trigger if you want". >>> >>> Adding a trigger just begs the question as to why we are bothering in >>> the first place, since this functionality could already be added by >>> INSERT, UPDATE or DELETE triggers, if they are a full replacement for >>> this feature. The only answer is "ease of use" >>> >>> We can easily add syntax like this >>> >>> [ROW SECURITY CHECK ( .... ) [ON [ ALL | INSERT, UPDATE, DELETE, SELECT >>> [..,]]]] >>> >>> with the default being "ALL" >>> >> I think it is flaw of Oracle. :-) > > Agreed > >> In case when user can define leakable function, it enables to leak contents >> of invisible rows at the timing when executor fetch the rows, prior to >> modification >> stage, even if we allows to configure individual row-security policies >> for SELECT >> and DELETE or UPDATE commands. >> My preference is one policy on a particular table for all the commands. > > Yes, only one security policy allowed. > > Question is, should we offer the option to enforce it on a subset of > command types. > > That isn't anything I can see a need for myself. > It is not hard to support a feature not to apply security policy on particular command types, from implementation perspective. So, my preference is to support only the behavior corresponding to above "ALL" option, then support per commands basis when we got strong demands. How about your thought?
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
