On Jan 26, 2008 3:06 PM, NUWAN LIYANAGE <alnuwan@xxxxxxxxx> wrote:
> Yes, I was thinking of doing a pg_dumpall, but my only worry was that the
> singl file is going to be pretty large. I guess I don't have to worry too
> much about that.
> But my question to you sir is, If I want to create the development db using
> this pg dump file, how do I actually edit create tablespace statements so
> they will be created in the directory I want them to be. Or should I even
> worry about this.. (I want my data directory to be in E: drive including all
> the tablespaces.)
Take a look through the docs on pg_dump and pg_dumpall.
A few of the options to look at are the ones to dump just data or just
schema. Quite often you don't need the data, just the schema, for
development. "pg_dump -s dbname" will dump just the schema, and
"pg_dumpall --globals" will dump just the global database info, i.e.
usernames, tablespaces, etc...
Then just edit in your favorite text editor and point the resulting
file(s) at your dev db with psql f mydump.sql where mydump.sql is the
file you got from one or more of the above operations.
After that, I highly recommend that any changes you wish to make, do
so with .sql scripts (stored in your favorite version control system),
so that you can then apply them to your production database later with
minimal fuss.
Note that any changes that should be "all or nothing" to the
production database can be applied in a transaction (i.e. wrapped in a
begin/commit pair) and then either all or none of the changes will be
made...
example
begin;
create table abc ....
alter table xyz ...
insert ...
commit;
if any of those commands fail (things like creating unique indexes
might fail on production where they didn't in development) then no
harm, no foul, just figure out what went wrong and update your script
so it takes care of those problems.
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
