Tom Lane wrote: <blockquote cite="mid:6866.1199554748@sss.pgh.pa.us" type="cite"><pre wrap="">Peter Eisentraut <a
class="moz-txt-link-rfc2396E"href="mailto:peter_e@gmx.net"><peter_e@gmx.net></a> writes: </pre><blockquote
type="cite"><prewrap="">Here is a patch that implements "localssl" as well. It is quite simple.
</pre></blockquote><prewrap="">The other area that would need some thought before we could consider
this "done" is the behavior of libpq's sslmode parameter. With the
patch as given, an SSL-capable libpq will *default* to using SSL over
sockets, which might be thought overkill; it is almost certainly
going to result in a performance penalty. Is this a reasonable default
behavior? Should sslmode be extended to allow specification of
different behaviors for sockets vs. TCP</pre></blockquote> Does the patch handle patched clients connecting to
unpatchedservers and vice versa?<br /><br /> I am undecided whether I will use this proposed functionality or not. I
wouldlike to tighten up security (only a few people have access to the machine, but even a few may be a few too many?).
Cryptographicauthentication and encrypted data stream cost is high compared to no cryptographic authentication or
encrypteddata streams. I don't know if it would impact me or not. Peter: Have you tried running a benchmark of localssl
vslocalnossl?<br /><br /> Cheers,<br /> mark<br /><br /><pre class="moz-signature" cols="72">--
Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc"><mark@mielke.cc></a>
</pre>