Date: Mon, 14 Feb 2000 11:05:32 -0500
From: Joel Reed <jreed@support.ddiworld.com>
To: pgsql-interfaces@postgresql.org
Subject: Re: [INTERFACES] libpq patch for binding tuples in a result set to
	user allocated memory
Message-ID: <20000214110532.G8823@support.ddiworld.com>
References: <20000214095958.C8823@support.ddiworld.com>
	<18990.950543823@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <18990.950543823@sss.pgh.pa.us>;
	from tgl@sss.pgh.pa.us on Mon, Feb 14, 2000 at 10:57:03AM -0500

On Feb 14, tgl@sss.pgh.pa.us hacked the bitstream to say...
Tom> Joel Reed <jreed@support.ddiworld.com> writes:
Tom> > Having been used to being able to bind tuple data from a result set to
Tom> > user allocated memory (rather than having to copy the data out of the
Tom> > "libpq" like API's buffers to my memory locations) in my days working
Tom> > with ODBC, Oracle & SQLServer's C-API, i created the following patch
Tom> > which i thought i'd submit. I've included a README as well. 
Tom> 
Tom> I do not like this idea very much --- in the first place, it ties the
Tom> application far too tightly to internal representational details that
Tom> should be private to libpq, and in the second place the implementation
Tom> you offer is full of little gotchas like
Tom> 
Tom> >   a). construct an array of PGresAttValue's whose size is equal to the
Tom> >       number of columns in the result set. if you don't you'll core dump!
Tom> 
Tom> I really doubt that avoiding PQgetvalue() calls is worth taking those
Tom> kinds of risks and narrowing our options for future reimplementation of
Tom> the library and protocol.

i agree that it limits future choices. i'm just trying to port a ORCL/SQLServer
application to postgresql w/ the least possible change & w/o incurring
the copying overheaded currently in libpq.

Tom> 
Tom> In the long run we'll probably be moving to some more-modern interface
Tom> design like CORBA, which should help to address performance concerns
Tom> like these.

how would CORBA help?

thanks, jr

-- 
------------------------------------------------------------------------
Joel W. Reed                              http://ruby.ddiworld.com/jreed
----------------We're lost, but we're making good time.----------------