Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id E42ED475A69 for ; Tue, 13 Aug 2002 18:15:20 -0400 (EDT) Received: from newsguy.com (smtp.newsguy.com [216.148.53.69]) by postgresql.org (Postfix) with ESMTP id 53A154759F6 for ; Tue, 13 Aug 2002 18:15:20 -0400 (EDT) Received: (from pacquet@localhost) by newsguy.com (8.9.1a/8.9.1) id PAA79633; Tue, 13 Aug 2002 15:15:11 -0700 (PDT) Date: Tue, 13 Aug 2002 15:15:11 -0700 (PDT) Message-Id: <200208132215.PAA79633@newsguy.com> X-Mailer: Direct Read Email by Newsguy News Service To: tgl@sss.pgh.pa.us, pgsql-interfaces@postgresql.org From: pacquet@newsguy.com Subject: Re: PQputline in BINARY mode? X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200208/39 X-Sequence-Number: 3001 Thanks. Now I realize what should have been obvious: the command "COPY BINARY" is being executed by the backend, while PQputline() is a frontend routine. Duh. However, this is an embedded system, so some modest amount of backend-hacking is quite acceptable if the payoff is large enough. Do you have any pointers on implementing a variant of COPY BINARY <> FROM file that works out of memory instead of a file? At Tue, 13 Aug 2002 17:53:44 -0400, you wrote >pacquet@newsguy.com writes: >> the question is, can I combine both techniques, and use a programmatic >> interface to copy binary information? > >Nope. There's no support for binary COPY in the frontend/backend >protocol. This is one of the things I'd like to see fixed next time >we change the protocol. (That's a sufficiently painful thing that we >don't do it often --- the last time was release 6.4 --- but we're >considering a protocol rev for the next development cycle, 7.4.) > > regards, tom lane >