On 9 December 2012 06:21, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: > 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?
Very much agree that ALL should be the default, and only option for first commit of this feature. -- Simon Riggs 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
