People might be more interested in debating this topic with you if we hadn't discussed it at length just a couple months back. There wasn't consensus then that we had to offer an escape hatch, and you've not offered any argument that wasn't made before.
I'm simply presenting a problem for which I currently do not see any solution
(it's very important for us to be able to restore db within a reasonable amount
of time). If there's no solution and none is planned, then we cannot use pgsql,
can we?
You're simply presenting a problem that isn't there in the first place. If you really feel the need to shoot yourself in the foot, use separate schema and data dumps and do the latter with "-X disable-triggers".
And now will you please put it to rest?
If this is not a prio 1 problem, what are then the prio one problems??? You are a developer, right? Did you ever manage a big database in production? What shoul I tell to my customers when they want to have a not that big database (100 GB) in PostgreSQL: "I am sorry, but we are not able to do performant backups, I recommend you to choos ORACLE instead???". Is it this we/you recommend?
Regards Oli
-------------------------------------------------------
Oli Sennhauser Database-Engineer (Oracle & PostgreSQL) Rebenweg 6 CH - 8610 Uster / Switzerland
Phone (+41) 1 940 24 82 or Mobile (+41) 79 450 49 14 e-Mail [EMAIL PROTECTED] Website http://mypage.bluewin.ch/shinguz/PostgreSQL/
Secure (signed/encrypted) e-Mail with a Free Personal SwissSign ID: http://www.swisssign.ch
Import the SwissSign Root Certificate: http://swisssign.net/cgi-bin/trust/import
smime.p7s
Description: S/MIME Cryptographic Signature
