* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >> Stephen Frost <sfrost@snowman.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.
It would be a dump of what you're allowed to see, rather than an error
saying you couldn't dump something you couldn't see, which is the
alternative we're talking about here. Even if you've got a dependency
to something-or-other, if you don't have access to it, then you're
going to get an error.
In practice, you have to make sure to remember to include all of your
schemas when you pg_dump, and don't get it wrong or you'll get an error
(you don't have access to some schema referenced) or a subset of what
you intended (you forgot to include one you meant to). That is not a
better user experience than being able to say "dump out everything I've
got access to."
In many, many use-cases that's exactly what you want. pg_dump is more
than just a whole-database backup tool, and when it's used as a
whole-database backup tool, you'll need to make sure it has BYPASSRLS or
is a superuser or you could end up getting errors. I don't see any
issue with that.
If the policies are incorrect then that'd be a problem, but I'm
certainly hopeful that we'd be able to get that right.
Thanks!
Stephen
