* Tom Lane (t...@sss.pgh.pa.us) wrote: > Gilles Darold <gilles.dar...@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
signature.asc
Description: Digital signature