On Thu, Nov 13, 2014 at 08:24:36PM -0500, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > What's bothering me is that I see this in pg_dumpall output from a 9.4 > > or earlier database: > > > > ALTER ROLE postgres WITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN > > REPLICATION NOBYPASSRLS; > > Ah, yeah, good point. > > > That means that if you do a pg_upgrade from a 9.4 database, your built-in > > superuser will now not have rolbypassrls set, though it does in a database > > built in any other way. Even if that doesn't have any functional effect, > > it's a recipe for confusion IMO. So I think that the code ought to be > > "usesuper as rolbypassrls" rather than "false as rolbypassrls" for > > back branches. > > > > The only other similar case is rolreplication, which perhaps also ought > > to read as usesuper for old branches. > > Agreed. I'll take care of both and we'll make sure the new role > attributes being added will do the same for upgrades also.
That would make pg_dumpall less faithful for every role other than the bootstrap superuser, a net loss. It would be defensible to do this for BOOTSTRAP_SUPERUSERID only. Even there I prefer the current behavior; this is just another of many fine details that pg_upgrade reproduces more precisely than other pg_dumpall/pg_dump invocations. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
