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.----------------
