Re: pg_dump and pg_dumpall in real life

Andrew Dunstan wrote
> A general ability to rename things would be good. In particular, 
> restoring schema x into schema y or table x into table y would be very 
> useful, especially if you need to be able to compare old with new.

compare old and new what?  I would imagine that schema comparisons would be
much easier if the only thing that is different is the database name and you
compare database "old" to database "new".

Are there any existing threads or posts, that you recollect, that detail
solid use-cases for "clone-and-rename" mechanics?  I don't seem to recall
anything in the past year or so but my coverage is probably only about 70%
in that timeframe.

SQL seems particularly unfriendly to renaming and runtime name resolution in
general (largely due to caching effects).  Some kind of alias mechanism
makes sense conceptually but the performance hit for such isn't likely to be
worth incurring.

I could see having table name aliases so that raw data in a dump from one
database could be restored into another but I'd likely require that the user
be able to generate the target schema from source themselves.  That would
facilitate the use-case where the DBA/programmer is able to fully recreate
their schema from source and only require that actual data be restored into
the newly created database.  I can see where grants may fall into a grey
middle-area but functions/view/triggers and the like would need to be
synchronized with any schema naming changes and that should, IMO, be driven
from source and not facilitated by a dump/restore process.

David J.






--
View this message in context:
http://postgresql.1045698.n5.nabble.com/pg-dump-and-pg-dumpall-in-real-life-tp5777718p5777816.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.