| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Joe Conway <mail(at)joeconway(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Multi-tenancy with RLS |
| Date: | 2016-01-15 16:45:29 |
| Message-ID: | 22059.1452876329@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> Stephen Frost <sfrost(at)snowman(dot)net> writes:
>>> I don't follow how this would destroy the ability to run pg_dump.
>>> Ideally, we'd have a result where a user could run pg_dump without
>>> having to apply any filters of their own and they'd get a dump of all
>>> objects they're allowed to see.
>> You mean, other than the fact that pg_dump sets row_security = off
>> to ensure that what it's seeing *isn't* filtered.
> There's a specific option to turn it back on already though.
Whereupon you'd have no certainty that what you got represented a
complete dump of your own data.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2016-01-15 16:49:23 | Re: dealing with extension dependencies that aren't quite 'e' |
| Previous Message | Benedikt Grundmann | 2016-01-15 16:39:18 | Re: Death by regexp_replace |