>>> 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 oli.sennhauser@bluewin.ch
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
