Re: Practical impediment to supporting multiple SSL libraries

On Thu, Apr 13, 2006 at 11:54:33AM -0400, Stephen Frost wrote:

<snip>

> Sure you could but you're forced to do more copying around of the data
> (copy into the PGresAttValue, copy out of it into your structure array).
> If you want something more complex then a callback makes more sense but
> I'm of the opinion that we're talking about a 90/10 or 80/20 split here
> in terms of dump-into-memory array vs. do-something-more-complicated.

I think we're talking cross-purposes here. You seem to be interested in
making another way to get the data. What I'm trying to do is create an
interface flexible enough that no-one would ever want write their own
wire-protocol parser because they can get libpq to do it. This probably
falls into the 10% portion.

The use of PGresAttValue was deliberate. libpq already uses this so it
costs nothing. Also, the memory pointed to is allocated very cheaply
within libpq. The intention is that users can either choose to use that
(great for read-only, i.e. 90% of the time) or copy it *only* if they
want to (what psqlODBC wants to do).

Basically, your solution doesn't handle the use case of psqlODBC which
is specifically what I'm aiming at here...

> Just to point out, we could do what you're proposing by letting people
> look at PQresult during an async too.. ;) Except, of course, libpq
> would need to allocate/deallocate all the PQresults and have some way of
> knowing which have been used by the caller and which havn't.

Eh? You only need one PQresult...

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.