Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154]) by hub.org (8.10.1/8.10.1) with ESMTP id e9CF46r69477 for ; Thu, 12 Oct 2000 11:04:07 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.0/8.11.0) with ESMTP id e9CF45B26211; Thu, 12 Oct 2000 11:04:05 -0400 (EDT) To: keke abe cc: pgsql-interfaces@postgresql.org Subject: Re: COPY BINARY to stdout In-reply-to: <19340906010007.3839@mail.gol.com> References: <19340906010007.3839@mail.gol.com> Comments: In-reply-to keke abe message dated "Thu, 12 Oct 2000 16:28:23 +0900" Date: Thu, 12 Oct 2000 11:04:04 -0400 Message-ID: <26208.971363044@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200010/102 X-Sequence-Number: 1459 keke abe writes: > After receiving the 'H' (COPY_OUT) message from the backend, > how should I tell if the incoming data is in binary format or > not? You don't; you just have to know whether you asked for binary or text copy. At the moment binary copy to/from the frontend is disabled anyway: /* * This restriction is unfortunate, but necessary until the frontend * COPY protocol is redesigned to be binary-safe... */ if (pipe && binary) elog(ERROR, "COPY BINARY is not supported to stdout or from stdin"); There's a TODO list item to invent a less brain-dead format for binary COPY data. (The binary cursor representation is not too bad, maybe just use that.) In the meantime I suggest forget about COPY BINARY and use DECLARE BINARY CURSOR instead. regards, tom lane