On 2013-09-01 16:38:51 +0300, Heikki Linnakangas wrote: > On 30.08.2013 22:57, Josh Berkus wrote: > >Right now, the primary tool for doing row filtering for MTA is Veil, > >which has numerous and well-known limitations. If RLS has fewer > >limitations, or is easier to deploy, maintain, and/or understand, then > >it's a valuable feature for that user base, even if it doesn't address > >the covert channels we've brought up at all. > > > >That is, if RLS is your*second* level of defense, instead of your > >primary defense, covert channels are not a make-or-break issue. It just > >has to be better than what we had before. > > > >Note that I have NOT done an evaluation of Veil vs. RLS for MTA at this > >point. I'm hoping someone else will ;-) > > I'd also like to hear how Veil differs from RLS. From what I've understood > this far, they are the same in terms of what you can and cannot do. > > To phrase it differently: We already have RLS. It's shipped as an extension > called Veil. Now please explain what's wrong with that statement, if > anything.
I don't think veil really is an argument for much in this discussion. I don't know who in this discussion has used it, I have. Admittedly a good bit ago, 8.2, 8.3 days I think. There hasn't been much fundamental development since though, if my quick look is right. Veil gives you a rather low level toolbox for developing an RLS and you're left with a *huge* amount of work needed ontop. It basically gives you a bunch of new datatypes (sets, bitmaps, ranges) and provides some support for sharing variables across backends (shared memory). That's nearly it. Greetings, Andres Freund -- Andres Freund 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
