On Thu, Jun 14, 2012 at 02:43:04PM -0400, Tom Lane wrote:
> Euler Taveira <euler@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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
