Re: Dumping roles improvements?

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Dumping roles improvements?
Date: 2011-10-11 23:39:17
Message-ID: 4E94D3A5.1030005@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> There seems to be agreement on something for (2), and it won't be hard.
> (1) would probably be much more complex. Essentially we'd need to add a
> new object type for roles, I think. But won't (2) give you most of what
> you need for (1) anyway? AIUI, your problem is that the roles might not
> exist, and so some or all of the dump will fail. But if you have (2) and
> dump the roles without passwords and restore them before running
> pg_restore that wouldn't happen. It won't be one command but it will be
> two or three pretty easy commands.

These serve two different purposes.

The reason I want to have the dependant roles created as part of a
database dump is so that we can ship around dump files as a single file,
and restore them with a single command. This is considerably simpler
than the current requirements, which are:

1. pg_dumpall the roles
2. pg_dump the database
3. tar both files
4. ship file
5. untar both files
6. psql the role file
7. pg_restore the database file

Since the above is something I'm doing on around 11 different machines
between once a day and once a week, eliminating the 4 extra steps would
be really nice.

However, we'd also need CREATE OR REPLACE ROLE to really integrate
shipping database copies. Without that, including roles in the database
dump doesn't help that much.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message hans wulf 2011-10-12 00:08:18 Will Index-only-scan be in 9.2
Previous Message Joe Conway 2011-10-11 23:06:22 Re: SET variable - Permission issues