Re: Practical impediment to supporting multiple SSL libraries

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, pgsql-hackers(at)postgresql(dot)org, Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp>
Subject: Re: Practical impediment to supporting multiple SSL libraries
Date: 2006-04-13 13:07:56
Message-ID: 20060413130756.GH7362@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 13, 2006 at 08:32:34AM -0400, Stephen Frost wrote:
> * Martijn van Oosterhout (kleptog(at)svana(dot)org) wrote:
> > Hmm, the simplest improvement I can think of is one where you
> > register a callback that libpq calls whenever it has received a new
> > tuple.
>
> 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.

> It's actually pretty common (or seems to be anyway) to want to store the
> data from the query result into your own data structure. Yes, you could
> just use pointers all over the place but that means you're going to have
> to use things which understand PQresult everywhere as opposed to having a
> generic 'storage manager' with other generic things (index creator,
> aggregator, etc) which can be used with more than just PQresults.

<snip>

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

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

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sergey E. Koposov 2006-04-13 13:21:12 two-argument aggregates and SQL 2003
Previous Message Dave Page 2006-04-13 13:07:19 Re: Practical impediment to supporting multiple SSL libraries