| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Noah Misch <noah(at)leadboat(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Joe Conway <mail(at)joeconway(dot)com> |
| Subject: | Re: row_security GUC, BYPASSRLS |
| Date: | 2015-09-15 16:10:43 |
| Message-ID: | 5198.1442333443@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Sep 15, 2015 at 1:00 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>> It also requires a DBA unwilling to
>> furnish test accounts to custodians of sensitive data. With or without
>> row_security=force, such a team is on the outer perimeter of the audience able
>> to benefit from RLS. Nonetheless, I'd welcome a replacement test aid.
> I can't argue with that, I suppose, but I think row_security=force is
> a pretty useful convenience. If we must remove it, so be it, but I'd
> be a little sad.
Keep in mind that if you have an uncooperative DBA on your production
system, you can always test your policy to your heart's content on a
playpen installation. In fact, most people would consider that good
engineering practice anyway, rather than pushing untested code directly
into production.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joe Conway | 2015-09-15 16:23:49 | Re: row_security GUC, BYPASSRLS |
| Previous Message | Jan Wieck | 2015-09-15 16:02:26 | Re: [COMMITTERS] pgsql: Fix an O(N^2) problem in foreign key references. |