On Thu, Jun 14, 2012 at 02:43:04PM -0400, Tom Lane wrote: > Euler Taveira <eu...@timbira.com> writes: > > On 14-06-2012 02:19, Tom Lane wrote: > >> ... I especially think that importing bzip2 > >> is a pretty bad idea --- it's not only a new dependency, but bzip2's > >> compression versus speed tradeoff is entirely inappropriate for this > >> use-case. > > > I see, the idea is that bzip2 would be a compiled-in option (not enabled by > > default) just to give another compression option. > > I'm not particularly thrilled with "let's have more compression options > just to have options". Each such option you add is another source of > fail-to-connect incompatibilities (when either the client or the server > doesn't have it). Moreover, while there are a lot of compression > algorithms out there, a lot of them are completely unsuited for this > use-case. If memory serves, bzip2 for example requires fairly large > data blocks in order to get decent compression, which means you are > either going to get terrible compression or suffer very bad latency > when trying to apply it to a connection data stream. > > So I've got very little patience with the idea of "let's put in some > hooks and then great things will happen". It would be far better all > around if we supported exactly one, well-chosen, method. But really > I still don't see a reason not to let openssl do it for us.
Do we just need to document SSL's NULL encryption option? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
