On Thu, Oct 8, 2009 at 8:34 AM, Dimitri Fontaine <dfontaine@hi-media.com> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> 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".
>
> Yeah sorry I was to quick to answer. Basically having the bad rows
> returned to the client the same way EXPLAIN does feels strange. Not very
> scalable and sounds uneasy to manage client side...
I was thinking of returning the error messages, rather than the rows,
same as what is getting logged to the side table by the current patch.
As for table vs. result-set, let me just say that a patch that returns
result-set will be easier and more likely to be committed, and a
follow-on patch can add a feature to redirect it to a table (or maybe
we'll come up with another solution to that part, like WITH
copy_results AS (COPY ...) INSERT INTO ... SELECT ... FROM
copy_results), which would actually be far more powerful and with many
fewer definitional challenges).
> So it feels to me like when you talk about postponing the bad lines
> rejection handling you're in fact postponing it all, as that's the thing
> we're wanting this patch for. I couldn't really parse if your proposal
> is a step towards having a better rejection handling, though.
>
> Hope this clarifies it, sorry again for bad try at being terse,
Well, right now we are postponing EVERYTHING, because there is a week
left in the CommitFest and this patch isn't close to being
committable. The next time someone takes a crack at this, IMHO, it
should be broken into significantly smaller pieces. Exactly which of
those pieces gets done first is up to the patch author, of course, but
I don't see why someone couldn't have a workable patch with an
interesting subset of this functionality done in time for next CF,
especially given this code to hack on for a starting point.
...Robert