Re: COPY enhancements

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Cc: Emmanuel Cecchet <manu(at)asterdata(dot)com>, Emmanuel Cecchet <Emmanuel(dot)Cecchet(at)asterdata(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: COPY enhancements
Date: 2009-10-08 13:42:28
Message-ID: 603c8f070910080642p3d832df7o2dd7717be04b0e1f@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 8, 2009 at 8:34 AM, Dimitri Fontaine <dfontaine(at)hi-media(dot)com> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-10-08 13:58:53 Re: Review of "SQLDA support for ECPG"
Previous Message Simon Riggs 2009-10-08 12:40:36 Re: COPY enhancements