On Thu, Oct 8, 2009 at 4:42 AM, Dimitri Fontaine <dfontaine@hi-media.com> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> What's really bad about this is that a flag called "error_logging" is
>> actually changing the behavior of the command in a way that is far
>> more dramatic than (and doesn't actually have much to do with) error
>> logging. It's actually making a COPY command succeed that would
>> otherwise have failed. That's not just a logging change.
>
> That's what has been asked for, a COPY that is able to load the good
> rows in the presence of bad rows. I'd rather change the option name than
> the behavior. Pretty please.
I'm a little mystified by this response since I spent several
paragraphs following the one that you have quoted here explaining how
I think we should approach the problem of providing the features that
are currently all encapsulated under the mantle of "error logging". I
don't think changing the name is going to be sufficient by itself,
but, well, go back and read what I suggested (and comment on it if you
have any thoughts or just want to say +/-1).
Lest there be any unclarity, I am NOT trying to shoot down this
feature with my laser-powered bazooka. What I AM trying to do is
point out - as early as possible - things that I believe that a
hypothetical committer would likely also object to. That's the major
point of having non-committer reviewers, at least AIUI. I am not
opposed to the underlying features except to the extent that they have
unfixable design problems. I believe that they CURRENTLY have design
problems, but I'm hopeful that, with some discussion, we can agree on
a way forward. I think, though, that we should try to keep the
discussion technical (how well does this work?) rather than a
referendum on the underlying feature (which someone might object to,
but the sheer level of interest in this patch is a fairly compelling
argument that there is support for at least some of what it is trying
to do).
...Robert