* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Gilles Darold <gilles.darold@dalibo.com> writes:
> > In the same query there is another bug introduced by commit 491c029
> > that add Row-Level Security Policies. Current master code has a broken
> > pg_dumpall when trying to dump from a backend lower than 8.1.
>
> Actually, I think that code is not just under-tested but poorly thought
> out. It will dump ALL roles from a pre-9.5 database with NOBYPASSRLS;
> even superusers. I would think that existing superusers ought to be
> assumed to have the BYPASSRLS property, no? (This assumes that the
> property means anything at all for superusers, which maybe it doesn't;
> but if so we probably ought to be forcing it true for superusers to
> avoid confusion.)
Superusers are always considered to have it, regardless of if the option
is set for them and so, no, it isn't relevant to superusers (that's true
for nearly all of the role attribute options, as I recall..). It can be
reworked to set it for superusers when it's dumped, but I'm not sure
that really helps. Consider that creating a new superuser role doesn't
go and set CREATEROLE or any of the other attributes, yet a superuser is
considered to have those rights regardless.
If we want to really force it to 'true' for superusers then we should
change all the role attributes to act in the same way and to be set
whenever superuser is set. It might get annoying though for users who
grant superuser and then revoke it- what do we do then? The only sane
answer seems to be "leave those other attributes in place", but that
could certainly be confusing for users.
Still, I don't feel strongly either way about it- but whatever we do
here, we should remember to do the same for the other new role
attributes under discussion to be added.
I'm happy to fix it either way (and fix it for 8.1, and back to.. what?
Postgres95?)
Thanks!
Stephen