Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA68873 for ; Mon, 14 Feb 2000 10:57:12 -0500 (EST) (envelope-from tgl@sss.pgh.pa.us) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA18993; Mon, 14 Feb 2000 10:57:04 -0500 (EST) To: Joel Reed cc: pgsql-interfaces@postgreSQL.org Subject: Re: [INTERFACES] libpq patch for binding tuples in a result set to user allocated memory In-reply-to: <20000214095958.C8823@support.ddiworld.com> References: <20000214095958.C8823@support.ddiworld.com> Comments: In-reply-to Joel Reed message dated "Mon, 14 Feb 2000 09:59:58 -0500" Date: Mon, 14 Feb 2000 10:57:03 -0500 Message-ID: <18990.950543823@sss.pgh.pa.us> From: Tom Lane Joel Reed writes: > Having been used to being able to bind tuple data from a result set to > user allocated memory (rather than having to copy the data out of the > "libpq" like API's buffers to my memory locations) in my days working > with ODBC, Oracle & SQLServer's C-API, i created the following patch > which i thought i'd submit. I've included a README as well. I do not like this idea very much --- in the first place, it ties the application far too tightly to internal representational details that should be private to libpq, and in the second place the implementation you offer is full of little gotchas like > a). construct an array of PGresAttValue's whose size is equal to the > number of columns in the result set. if you don't you'll core dump! I really doubt that avoiding PQgetvalue() calls is worth taking those kinds of risks and narrowing our options for future reimplementation of the library and protocol. In the long run we'll probably be moving to some more-modern interface design like CORBA, which should help to address performance concerns like these. regards, tom lane