On Thu, Oct 8, 2009 at 8:34 AM, Dimitri Fontaine <dfonta...@hi-media.com> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers