Re: COPY enhancements

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Robert Haas <robertmhaas(at)gmail(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 12:34:33
Message-ID: 87pr8ydpye.fsf@hi-media-techno.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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...

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,

Regards,
--
Dimitri Fontaine
PostgreSQL DBA, Architecte

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Tiikkaja 2009-10-08 12:40:10 Re: Writeable CTEs and side effects
Previous Message Robert Haas 2009-10-08 11:52:56 Re: Review of "SQLDA support for ECPG"