| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, 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 15:56:38 |
| Message-ID: | 20666.1144943798@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
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.
> 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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2006-04-13 16:02:56 | Re: Practical impediment to supporting multiple SSL libraries |
| Previous Message | Stephen Frost | 2006-04-13 15:54:33 | Re: Practical impediment to supporting multiple SSL libraries |