On Thu, Jul 30, 2015 at 10:37:33PM -0400, Adam Brightwell wrote: > On Thu, Jul 30, 2015 at 02:26:34PM -0400, Robert Haas wrote: > >> 1. "pg_dumpall -g" > >> 2. "pg_dump --create" per database > > > > Gah, OK, I see your point. But we better document this, because if > > you need a PhD in PostgreSQL-ology to take a backup, we're not in a > > good place.
Definitely. > Agreed. Though, honestly, I find this to be a cumbersome approach. I > think it just makes things more confusing, even if it is well > documented. Perhaps it might be necessary as a bridge to get to a > better place. But my first question as an end user would be, 'why > can't one tool do this?'. "pg_dumpall" (without -g) is that one tool. It has excellent dump fidelity. It lacks the slicing and dump format options of pg_dump, which are important to many sites. > Also, by using 'pg_dumpall -g' aren't you > potentially getting things that you don't want/need/care about? For > instance, if database 'foo' is owned by 'user1' and database 'bar' is > owned by 'user2' and neither have any knowledge/relation of/to the > other, then when I dump 'foo', in this manner, wouldn't I also be > including 'user2'? Said differently, a restore of a 'foo'-only dump > would also include a 'bar' related role. That seems like a bad idea, > IMHO. Maybe it can't be avoided, but I'd expect that only relevant > information for the database being dumped would be included. Nothing in core PostgreSQL attempts to answer the high-level question "Is user1 relevant to database bar?" PostgreSQL has no one concept of a role's relevance to databases. Some reasonable heuristics come to mind, but nothing I'd be eager to memorialize in a core tool like pg_dumpall. Thanks, nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
