Re: Practical impediment to supporting multiple SSL libraries

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> The only reason I can see for offering any new feature in this area is
>> to cater to apps that want to transform the data representation
>> on-the-fly, not merely dump it into an area that will be the functional
>> equivalent of a PGresult. So it really has to be a callback.

> It's only the functional equivalent when you think all the world is a
> Postgres app, which is just not the case.

If we are dumping data into a simple memory block in a format dictated
by libpq, then we haven't done a thing to make the app's use of that
data independent of libpq. Furthermore, because that format has to be
generalized (variable-length fields, etc), it will not be noticeably
easier to use than the existing PQresult API.

What I would envision as a typical use of a callback is to convert the
data and store it in a C struct designed specifically for a particular
query's known result structure (say, a few ints, a string of a known
maximum length, etc). libpq can't do that, but a callback could do it
easily.

The fixed-memory-block approach also falls over when considering results
of uncertain maximum size. Lastly, it doesn't seem to me to respond at
all to the ODBC needs that started this thread: IIUC, they want each row
separately malloc'd so that they can free selected rows from the
completed resultset.

>>> The other issue with a callback is that libpq would have
>>> to either call the callback for each value (not my preference)
>>
>> Why not? That would eliminate a number of problems.

> For one thing, it's certainly possible the callback (to do a data
> transform like you're suggesting) would want access to the other
> information in a given tuple. Having to store a partial tuple in a
> temporary area which has to be built up to the full tuple before you can
> actually process it wouldn't be all that great.

So instead, you'd prefer to *always* store partial tuples in a temporary
area, thereby making sure the independent-field-conversions case has
performance just as bad as the dependent-conversions case.
I can't follow that reasoning.

regards, tom lane