On Fri, Nov 14, 2014 at 08:39:28PM -0500, Stephen Frost wrote: > * Noah Misch (n...@leadboat.com) wrote: > > So, if you desire to make this consistent, I recommend using > > rolreplication's > > treatment as the gold standard. That is to say, when dumping from an older > > version, set to false any of these role attributes not existing in that > > version. Robert's proposal to emit neither NOBYPASSRLS nor BYPASSRLS is a > > reasonable alternative, though less so for "pg_dumpall --clean". It would > > be > > defensible to send NOBYPASSRLS under --clean and omit the option otherwise; > > consider that my second choice. > > I don't see the point in including them for --clean..? --clean states > that DROP commands would be added, not that existing roles would be > adjusted in some way.
It does state that, but note this comment in dumpRoles(): /* * We dump CREATE ROLE followed by ALTER ROLE to ensure that the role * will acquire the right properties even if it already exists (ie, it * won't hurt for the CREATE to fail). This is particularly important * for the role we are connected as, since even with --clean we will * have failed to drop it. binary_upgrade cannot generate any errors, * so we assume the current role is already created. */ Under --clean, "the right properties" are those the role would have had if the DROP ROLE had succeeded. Those are necessarily independent of the pre-DROP version of the role. (Otherwise, you potentially get different outcomes depending on which superuser restored the --clean dump.) > As for using 'always false'- I tend to think Robert actually has it > better by using the default for users. Consider rolinherit- that > defaults to 'true' and while it would technically be more 'safe' to set > it to false, it wouldn't have matched what we provided under the user / > group system prior to roles. Doing this would also reduce clutter in > pg_dumpall output. My arguments and conclusion apply only to the permission-like attributes that are subsets of SUPERUSER. rolinherit is indeed not in that category. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers