Tom, > [ shrug... ] Everybody in the world is going to want their own little > problem to be handled in the fast path. And soon it won't be so fast > anymore. I think it is perfectly reasonable to insist that the fast > path is only for "clean" data import.
Why? No, really. It's not as if we don't have the ability to measure performance impact. It's reasonable to make a requirement that new options to COPY shouldn't slow it down noticeably if those options aren't used. And we can test that, and even make such testing part of the patch review. But ... fault-tolerant COPY is one of our biggest user requests/complaints. At user group meetings and the like, I get asked about it probably every third gathering of users I'm at. While it's not as critical as log-based replication, it's also not nearly as hard to integrate and review. I fully support the idea that we need to have the extended syntax for these new COPY options. But we should make COPY take an alternate path for fault-tolerant COPY only if it's shown that adding these options slows down database restore. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers