Re: Practical impediment to supporting multiple SSL libraries

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > I can see how having a callback would be useful though I think for a
> > good number of cases it's just going to be populating a memory region
> > with it and we could cover that common case by providing an API for
> > exactly that.
>
> We already have that: it's called the existing libpq API.

Right, and it sucks for doing large amounts of transfer through it.

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

> > 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. This is much less true
for the contents of an entire table (that you would need it all before
being able to perform the transforms). It would also be an awful lot of
calls.

Thanks,

Stephen