No, RLS does not necessarily require separate database users. Using database users is one relatively obvious way to use the feature, but you can very well do something like 'SELECT myapp_set_current_user(...)' or something, and use a variable securely set therein for the row restrictions.

Interesting. I didn't think about doing that. 9.2 makes that much easier to do http://dba.stackexchange.com/questions/97095/set-session-cus...

Yep. We do this where I work (the 9.4 equivalent using SECURITY BARRIER views) and it is extremely useful.

It's probably unsuitable for public facing sites, but for line of business applications it could be a real win. I would much rather have enforcement down to the data level.

It's probably is sutible for public facing sites, just not globablly.

Little bobby tables doesn't need the ability to dump your users or credit cards, even if he does need access to all the blog posts.

I have to read up on the feature a bit more, but it sounds a potentially massive win if you build the support into an orm / framework.

Yes, but it's not harder to have many db users vs many app users. There's even an extension to sync pg users with ldap

I'm not saying it's _hard_, it's just _different_ and would be a challenging migration for established apps as I don't know of any framework's authentication system that works like that.

Also, why would you sync pg users in ldap? pg can auth against ldap.

> Also, why would you sync pg users in ldap? pg can auth against ldap.

I figured out why: To pull roles/groups into the database from ldap.