Re: Practical impediment to supporting multiple SSL libraries

* Martijn van Oosterhout (kleptog(at)svana(dot)org) wrote:
> On Thu, Apr 13, 2006 at 08:32:34AM -0400, Stephen Frost wrote:
> > You wouldn't want it on every tuple as that'd get expensive through
> > function calls.
>
> Why not? Internally we call pqAddTuple for every tuple, calling a user
> function instead is hardly going to be more expensive. Also, I was
> thinking of the situation where the user function could set a flag
> so the eventual caller of (perhaps) PQconsumeInput knows that it's got
> enough for now.

Hrmpf, the fact that we have a different call we make for every tuple
anyway isn't exactly encouraging to me.

> > You don't provide a callback, you have the user provide a memory region
> > to libpq which libpq can then fill in. It's really not that difficult,
> > the API would really look quite a bit like PQexecParams, ie:
>
> Except in the case of psqlODBC, it wants to be able to malloc/free()
> each field, which your method doesn't solve. Also, it doesn't solve the
> duplicate memory use, nor the retreiving of rows before the resultset
> is complete.

I don't entirely follow why you think it wouldn't solve the duplicate
memory use (except perhaps in the psqlODBC case if they decide to just
grab a bunch of tuples into one area and then go through and malloc/free
each one after that, not exactly what I'd suggest...). The basic idea
was actually modeled off of 'read'- you get back what's currently
available, which might not be the full set you asked for so far. I
think perhaps you're assuming that my suggestion would just be an
overlay on top of the existing libpq PQgetReult which would just turn
around and call PQgetResult to fill in the memory region provided by the
user- entirely *not* the case... Perhaps I should have used 'PQconn'
instead of 'PQresult' as the first argument and that would have been
clearer.

Additionally, honestly, this is very similar to how Oracle's multi-row
retrival works... It uses two functions (one for setup into its own
structure and then one for actually getting rows) but the basic idea is
the same.

> > If we want to do conversion of the data in some way then we may need to
> > expand this to include that ability (but I don't think PQgetvalue does,
> > so...).
>
> I think a callback is much easier. As a bonus the user could specify
> that libpq doesn't need to remember the rows. Memory savings.

My solution didn't have libpq remembering the rows...

Thanks,

Stephen