--- Andreas Pflug <[EMAIL PROTECTED]> wrote:Agreed. This might be useful for replication purposes too; in MSSQL, you can write "CREATE TRIGGER ... NOT FOR REPLICATION". I'd like to see a transaction safe way (ENABLE/DISABLE TRIGGER command) for this.
Yes, I mentioned it just a few days when discussing dependency in pg_dump.
This is somewhat complementary to WAL and PITR. I'm seeking for a fast way to dump and restore a complete database, like physical file copy, without shutting down the backend. I was thinking of a BACKUP command that streams out the files including any indexes and non-vacuumed tuples. A database recreated from that wouldn't be as clean as a pg_dump/pg_restored database, but it would be up much faster, and there wouldn't be any dependency problem.
This doesn't really replace pg_dump/pg_restore, because it probably wouldn't be able to upgrade a cluster. Still, it would be helpful for disaster recovery.
I think creating a FK without verification check is still needed, especially in
case if:
1) original db is corrupted
2) during cluster upgrade
3) there's a need to BACKUP/RESTORE a *schema* instead of db.
Thanks
__________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
