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. >> * psql \d support needed >> > Are you suggesting to print out full qualifiers of row-security? > Or, a mark to indicate whether row-security is configured, or not? One of those options, yes -- 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