On Fri, Jun 15, 2012 at 10:19 AM, Bruce Momjian <bruce@momjian.us> wrote:
> 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.
Agreed. I think there's probably arguments to be had for supporting
compression without openssl (see below), but I don't think we need to
have a whole set of potentially incompatible ways of doing it. Picking
one that's good for the common case and not completely crap for the
corner cases would be a better choice (meaning bzip2 is probably a
very bad choice).
>> 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?
Does the SSL NULL encryption+compression thing work if you're not
using openssl?
For one thing, some of us still hold a hope to support non-openssl
libraries in both libpq and server side, so it's something that would
need to be supported by the standard and thus available in most
libraries not to invalidate that.
Second, we also have things like the JDBC driver and the .Net driver
that don't use libpq. the JDBC driver uses the native java ssl
support, AFAIK. Does that one support the compression, and does it
support controlling it?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
