| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
| Cc: | 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 14:34:54 |
| Message-ID: | 19834.1144938894@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> Right. Would you see value in a more formal libpq "hijack-me" interface
> that would support making the initial connection and then handing off
> the rest to something else?
I think this would just be busywork... the way ODBC is doing it seems
fine to me. In any case, do we really want to encourage random apps to
bypass the library? For one thing, with an API such as you suggest,
it would really be libpq's problem to figure out what to do with regular
vs passthrough calls. As it stands, it's very obviously not libpq's
problem anymore once you hijack the socket.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2006-04-13 15:14:57 | Re: Practical impediment to supporting multiple SSL libraries |
| Previous Message | mark | 2006-04-13 14:20:10 | Re: GPUSort project |