<div dir="ltr">On Thu, Jun 27, 2013 at 11:40 PM, Leon Smith <span dir="ltr">&lt;<a href="mailto:leon.p.smith@gmail.com" target="_blank">leon.p.smith@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Yeah, eventually adding some level of understanding of the formats would be nice,   but honestly my immediate need is a higher-performance (and somewhat specialized) replication solution;  I only need a tiny bit of understanding of the data I&#39;m shipping from server to server.    But at the same time,  a complete solution would need to deal with all three formats and the numerous flavors thereof,  not just CSV.  I don&#39;t doubt that the current FromField/ToField interface isn&#39;t particularly well suited to dealing with copy data,  though.  =)<br>

</div></div></blockquote><div><br></div><div style>In response to a proposal to add COPY escaping functionality to libpq, Tom Lane pointed out that &quot;one of the key requirements for anything dealing with COPY is that it be fast&quot; [1].  postgresql-copy-escape as-is provides a faster way to insert data than multi-row INSERT.  We don&#39;t need to support all of the formats for this.  I didn&#39;t even implement COPY TO support since PostgreSQL returns result sets pretty efficiently through the normal interface.</div>

<div style><br></div><div style>Your case is even simpler: send COPY data from one server to another.  This shouldn&#39;t require packing/unpacking fields.</div><div><br></div><div> [1]: <a href="http://www.postgresql.org/message-id/19641.1331821069@sss.pgh.pa.us">http://www.postgresql.org/message-id/19641.1331821069@sss.pgh.pa.us</a></div>

<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>As for threadWaitWrite,  I understand that,  but the code is actually dead code at the moment because postgresql-simple doesn&#39;t use libpq connections in asynchronous mode;  it&#39;s just there for when postgresql-simple starts using async libpq calls.    Which is something I would like to do,  but it would also be a disaster on Windows at the moment.  I&#39;m thinking perhaps that the most sensible thing to do would be to reimplement the blocking libpq calls in haskell using nonblocking libpq calls,  and then only use this module on unix systems.    Hopefully that would cut down on the CPP hackery.<br>

</div>
</div>
</blockquote></div><br></div><div class="gmail_extra" style>The libpq source may be helpful.  Take a look at PQexecFinish in fe-exec.c, which reveals some interesting considerations:</div><div class="gmail_extra" style><br>

</div><div class="gmail_extra" style> * When PQexec is given multiple SQL commands, it discards all but the last PGresult, but it combines error messages from these results.</div><div class="gmail_extra" style><br></div>
<div class="gmail_extra" style>
 * When PQexec encounters a result status of PGRES_COPY_*, it stops returning results, to allow the application to perform the transfer.</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>One thing to bear in mind is that threadWait* can be interrupted on Unix (that&#39;s one motivation for using the async API in the first place).  You&#39;ll have to figure out what &#39;exec&#39; should do when interrupted while waiting for a result.  Perhaps it should use PQcancel to cancel the request, then continue waiting for results.  If interrupted yet again, a subsequent &#39;exec&#39; will need to call PQgetResult to discard results from the interrupted query before calling PQsendQuery again.</div>

</div>